From owner-ipng@sunroof.eng.sun.com Sat Mar 1 12:56:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h21Kuk7f001601; Sat, 1 Mar 2003 12:56:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h21KukoC001600; Sat, 1 Mar 2003 12:56:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h21Kug7f001593 for ; Sat, 1 Mar 2003 12:56:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h21KunVL009543 for ; Sat, 1 Mar 2003 12:56:49 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09774 for ; Sat, 1 Mar 2003 13:56:44 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 1 Mar 2003 20:56:43 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 1 Mar 2003 20:56:42 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 1 Mar 2003 20:56:42 Z Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 1 Mar 2003 20:56:41 Z From: Masataka Ohta Message-Id: <200303012044.FAA02442@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA02442; Sun, 2 Mar 2003 05:44:15 +0900 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C39@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Feb 24, 2003 08:09:30 pm" To: Michel Py Date: Sun, 2 Mar 2003 05:44:14 +0859 () CC: Kurt Erik Lindqvist , Iljitsch van Beijnum , Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel; > > Kurt Erik Lindqvist wrote: > > This I thought was more or less standard. I was talking about > > less than 100ms convergence. > > Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 > ms rtt. You might need to talk to a guy named Albert Einstein; he wrote > interesting RFCs about the speed of light that, as far as I know, have > not been debunked yet. A simple end to end solution is to send multiple copies of a data to multiple pathes. Mission critical application over SONET is already doing so and it is said that, even if a path fails, not even a single bit is lost. As for IP multihoming, it is already implemented with a VoIP protocol and is working fine. Senders send multiple copies of a RTP data. At the receivers, RTP takes care of duplicate packet deletion. Having a few voice streams is not a problem at all, of course. Masataka Ohta -------------------------------------------------------------------- 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 Mar 2 01:03:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h229387f004820; Sun, 2 Mar 2003 01:03:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h229370D004819; Sun, 2 Mar 2003 01:03:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h229337f004812 for ; Sun, 2 Mar 2003 01:03:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h2293CVK011802 for ; Sun, 2 Mar 2003 01:03:12 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16123 for ; Sun, 2 Mar 2003 02:03:06 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 2 Mar 2003 09:03:06 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 2 Mar 2003 09:03:05 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 2 Mar 2003 09:03:05 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 2 Mar 2003 09:03:05 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA23236; Sun, 2 Mar 2003 09:03:03 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA09884; Sun, 2 Mar 2003 09:03:02 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h22932003817; Sun, 2 Mar 2003 09:03:02 GMT Date: Sun, 2 Mar 2003 09:03:02 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com, dhcwg@ietf.org Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt] Message-Id: <20030302090302.GD3724@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com, dhcwg@ietf.org References: <20030227155714.A28766@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030227155714.A28766@sverresborg.uninett.no> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Feb 27, 2003 at 03:57:14PM +0100, Tim Chown wrote: > > On Thu, Feb 27, 2003 at 09:35:52AM +0200, Pekka Savola wrote: > > > > I hear many (two sets of groups) are implementing DHCPv6 either for: > > - configuration parameters > > - prefix delegation (for the lack of alternatives) > > I would just add a "flag wave" for 6NET's Deliverable D3.2.3 which reports > on DHCPv6 implementations which may be of interest to people here [apologies > if a pointer has already been posted - just dipping in :] Ooops - some people asked for the URL for this DHCPv6 implementation and test report - it's at: http://www.6net.org/publications/deliverables/D3.2.3.pdf 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 Mar 3 02:08:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23A8f7f009525; Mon, 3 Mar 2003 02:08:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23A8fU5009524; Mon, 3 Mar 2003 02:08:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23A8c7f009517 for ; Mon, 3 Mar 2003 02:08:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23A8jVL020023 for ; Mon, 3 Mar 2003 02:08:46 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12028 for ; Mon, 3 Mar 2003 03:08:36 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 09:46:37 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 09:45:49 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 09:45:48 Z Received: from dhcp-168-17-124.autonomica.se ([192.71.80.74] [192.71.80.74]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 09:45:46 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h239kxif011473; Mon, 3 Mar 2003 10:46:59 +0100 (CET) Date: Mon, 3 Mar 2003 10:46:59 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Iljitsch van Beijnum , Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303012044.FAA02442@necom830.hpcl.titech.ac.jp> Message-Id: <13EA0568-4D5D-11D7-ADF5-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A simple end to end solution is to send multiple copies of a data to > multiple pathes. Mission critical application over SONET is already > doing so and it is said that, even if a path fails, not even a single > bit is lost. No. - kurtis - -------------------------------------------------------------------- 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 Mar 3 03:50:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23BoL7f009947; Mon, 3 Mar 2003 03:50:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23BoKo1009946; Mon, 3 Mar 2003 03:50:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23BoH7f009939 for ; Mon, 3 Mar 2003 03:50:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23BoNVL004815 for ; Mon, 3 Mar 2003 03:50:24 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17267 for ; Mon, 3 Mar 2003 04:50:14 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:50:11 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:50:11 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:50:10 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:50:10 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18612; Mon, 3 Mar 2003 06:48:08 -0500 (EST) Message-Id: <200303031148.GAA18612@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-prefix-delegation-requirement-01.txt Date: Mon, 03 Mar 2003 06:48:08 -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 IP Version 6 Working Group Working Group of the IETF. Title : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa, R. Droms Filename : draft-ietf-ipv6-prefix-delegation-requirement-01.txt Pages : 5 Date : 2003-2-28 This document describes requirements about how an IPv6 address prefix should be delegated to an IPv6 subscriber's network (or 'site'). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ipv6-prefix-delegation-requirement-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-2-28125442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-prefix-delegation-requirement-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28125442.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 Mar 3 04:01:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23C117f010109; Mon, 3 Mar 2003 04:01:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23C10kt010108; Mon, 3 Mar 2003 04:01:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23C0u7f010101 for ; Mon, 3 Mar 2003 04:00:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23C15VL006154 for ; Mon, 3 Mar 2003 04:01:05 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23141 for ; Mon, 3 Mar 2003 05:00:57 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:47:27 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:47:24 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:47:24 Z Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:47:23 Z From: Masataka Ohta Message-Id: <200303031140.UAA02194@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA02194; Mon, 3 Mar 2003 20:39:52 +0859 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <13EA0568-4D5D-11D7-ADF5-000393AB1404@kurtis.pp.se> from Kurt Erik Lindqvist at "Mar 3, 2003 10:46:59 am" To: Kurt Erik Lindqvist Date: Mon, 3 Mar 2003 20:39:52 +0859 () CC: Michel Py , Iljitsch van Beijnum , Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurtis; > > A simple end to end solution is to send multiple copies of a data to > > multiple pathes. Mission critical application over SONET is already > > doing so and it is said that, even if a path fails, not even a single > > bit is lost. > > No. Which part are you arguing against? Masataka Ohta -------------------------------------------------------------------- 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 Mar 3 04:01:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23C1r7f010130; Mon, 3 Mar 2003 04:01:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23C1qNF010129; Mon, 3 Mar 2003 04:01:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23C1n7f010122 for ; Mon, 3 Mar 2003 04:01:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23C1vVL006339 for ; Mon, 3 Mar 2003 04:01:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13868 for ; Mon, 3 Mar 2003 05:01:50 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:50:11 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:48:14 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:50:10 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 11:50:09 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18592; Mon, 3 Mar 2003 06:48:04 -0500 (EST) Message-Id: <200303031148.GAA18592@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-rfc2012-update-02.txt Date: Mon, 03 Mar 2003 06:48:03 -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 IP Version 6 Working Group Working Group of the IETF. Title : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipv6-rfc2012-update-02.txt Pages : 23 Date : 2003-2-28 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) [5] in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ipv6-rfc2012-update-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-2-28125431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-rfc2012-update-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-rfc2012-update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28125431.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 Mar 3 04:47:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23Clm7f010985; Mon, 3 Mar 2003 04:47:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23ClmTO010984; Mon, 3 Mar 2003 04:47:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23Clj7f010977 for ; Mon, 3 Mar 2003 04:47:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23ClrVK000276 for ; Mon, 3 Mar 2003 04:47:54 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10565 for ; Mon, 3 Mar 2003 05:47:47 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 12:47:44 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 12:47:41 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 12:47:41 Z Received: from kirk.rvdp.org (kirk.rvdp.org [80.126.101.63]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 12:47:40 Z Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id h23ClXi23613 for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 13:47:33 +0100 (CET) Date: Mon, 3 Mar 2003 13:47:33 +0100 From: Ronald van der Pol To: ipng@sunroof.eng.sun.com Subject: SFO agenda? Message-Id: <20030303124733.GD22761@rvdp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Do we already have an agenda for SFO? rvdp -------------------------------------------------------------------- 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 Mar 3 07:21:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23FL27f012106; Mon, 3 Mar 2003 07:21:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23FL1js012105; Mon, 3 Mar 2003 07:21:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23FKw7f012098 for ; Mon, 3 Mar 2003 07:20:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23FL7VK029615 for ; Mon, 3 Mar 2003 07:21:07 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08056 for ; Mon, 3 Mar 2003 08:20:57 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 15:19:53 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 15:19:52 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 15:19:52 Z Received: from dtctxexchims03.ins.com ([198.76.72.38] [198.76.72.38]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 15:19:51 Z Message-Id: <5.2.0.9.2.20030303101343.02ca3d08@pop5.ins.com> X-Sender: schwei_p@pop5.ins.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 03 Mar 2003 10:19:31 -0500 To: Alain Durand , ipng@sunroof.eng.sun.com From: Paul Schweitzer Subject: Re: playground status In-Reply-To: <3E53D1B6.9040507@sun.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1708576==.ALT" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_1708576==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Alain, Any progress resolving the technical difficulties with "playground.sun.com". I was hoping to reference the web site for a client presentation (N. American ISP). Please reply at your convenience. Thanks, Paul Schweitzer International Network Services Philadelphia, PA. USA http://www.ins.com At 2/19/2003 10:49 AM -0800 Wednesday, Alain Durand wrote: >Hi, > >We are having some technical difficulties with the machine >playground.sun.com, so the web server and the mail archives >are not accessible at the moment, neither in IPv4 nor IPv6. >We are doing our best to resolve this matter as soon as possible. >In the meantime, please accept our apologies for the inconvenience. > > - Alain. > >-------------------------------------------------------------------- >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 >-------------------------------------------------------------------- --=====================_1708576==.ALT Content-Type: text/html; charset="us-ascii" Alain,

Any progress resolving the technical difficulties with "playground.sun.com". I was hoping to reference the web site for a client presentation (N. American ISP).

Please reply at your convenience.
Thanks,
Paul Schweitzer
International Network Services
Philadelphia, PA. USA
http://www.ins.com


At 2/19/2003 10:49 AM -0800 Wednesday, Alain Durand wrote:
Hi,

We are having some technical difficulties with the machine
playground.sun.com, so the web server and the mail archives
are not accessible at the moment, neither in IPv4 nor IPv6.
We are doing our best to resolve this matter as soon as possible.
In the meantime, please accept our apologies for the inconvenience.

   - Alain.

--------------------------------------------------------------------
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
--------------------------------------------------------------------
--=====================_1708576==.ALT-- -------------------------------------------------------------------- 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 Mar 3 08:10:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23GA87f012534; Mon, 3 Mar 2003 08:10:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23GA8SI012532; Mon, 3 Mar 2003 08:10:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23GA47f012525 for ; Mon, 3 Mar 2003 08:10:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23GADVK012478 for ; Mon, 3 Mar 2003 08:10:13 -0800 (PST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19246 for ; Mon, 3 Mar 2003 09:10:07 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HB600BKEKUZF6@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 03 Mar 2003 09:08:59 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HB600J5CKUXY5@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 03 Mar 2003 09:08:59 -0700 (MST) Date: Mon, 03 Mar 2003 08:10:11 -0800 From: Alain Durand Subject: Re: playground status In-reply-to: <5.2.0.9.2.20030303101343.02ca3d08@pop5.ins.com> To: Paul Schweitzer Cc: ipng@sunroof.eng.sun.com Message-id: <9C2227B0-4D92-11D7-B0C7-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: multipart/alternative; boundary="Boundary_(ID_bQj9juIQtCxvpGxOTjrrQA)" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Boundary_(ID_bQj9juIQtCxvpGxOTjrrQA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable The machine should be back shortly. I'll announced it on the mailing=20 list. when it will be back online. - Alain. On Monday, March 3, 2003, at 07:19 AM, Paul Schweitzer wrote: > Alain, > > Any progress resolving the technical difficulties with=20 > "playground.sun.com". I was hoping to reference the web site for a=20 > client presentation (N. American ISP). > > Please reply at your convenience. > Thanks, > Paul Schweitzer > International Network Services > Philadelphia, PA. USA > http://www.ins.com > > > At 2/19/2003 10:49 AM -0800 Wednesday, Alain Durand wrote: > > Hi, > > We are having some technical difficulties with the machine > playground.sun.com, so the web server and the mail archives > are not accessible at the moment, neither in IPv4 nor IPv6. > We are doing our best to resolve this matter as soon as possible. > In the meantime, please accept our apologies for the inconvenience. > > =A0=A0 - Alain. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 http://playground.sun.com/ipng > FTP archive:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > --Boundary_(ID_bQj9juIQtCxvpGxOTjrrQA) Content-type: text/enriched; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable The machine should be back shortly. I'll announced it on the mailing list. when it will be back online. - Alain. On Monday, March 3, 2003, at 07:19 AM, Paul Schweitzer wrote: Alain, Any progress resolving the technical difficulties with "playground.sun.com". I was hoping to reference the web site for a client presentation (N. American ISP). Please reply at your convenience. Thanks, Paul Schweitzer International Network Services Philadelphia, PA. USA 1999,1999,FFFFhttp://www.ins.com At 2/19/2003 10:49 AM -0800 Wednesday, Alain Durand wrote: Hi, We are having some technical difficulties with the machine playground.sun.com, so the web server and the mail archives are not accessible at the moment, neither in IPv4 nor IPv6. We are doing our best to resolve this matter as soon as possible. In the meantime, please accept our apologies for the inconvenience. =A0=A0 - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 = 1999,1999,FFFFhttp://playground.sun.com/i= png FTP archive:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 = 1999,1999,FFFFftp://playground.sun.com/pu= b/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- = --Boundary_(ID_bQj9juIQtCxvpGxOTjrrQA)-- -------------------------------------------------------------------- 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 Mar 3 10:08:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23I8h7f013713; Mon, 3 Mar 2003 10:08:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23I8hqn013712; Mon, 3 Mar 2003 10:08:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23I8e7f013705 for ; Mon, 3 Mar 2003 10:08:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23I8nVL001575 for ; Mon, 3 Mar 2003 10:08:49 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01628 for ; Mon, 3 Mar 2003 11:08:43 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:08:43 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:08:42 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:08:42 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:08:42 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA10250 for ; Mon, 3 Mar 2003 10:08:38 -0800 (PST) Message-Id: <5.1.0.14.2.20030303130201.035ac838@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Mar 2003 13:06:07 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: IPv6 WG Last Call on "Requirements for IPv6 prefix delegation" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is an IPv6 working group last call for comments on submitting the following document for consideration as an Informational RFC: Title : Requirements for IPv6 prefix delegation Author(s) : S. Miyakawa, R. Droms Filename : draft-ietf-ipv6-prefix-delegation-requirement-01.txt Pages : 5 Date : 2003-2-28 The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today on March 17, 2003. Margaret Wasserman / Bob Hinden -------------------------------------------------------------------- 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 Mar 3 10:50:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23IoN7f014636; Mon, 3 Mar 2003 10:50:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h23IoNVw014635; Mon, 3 Mar 2003 10:50:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h23IoJ7f014628 for ; Mon, 3 Mar 2003 10:50:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id h23IoSVL017061 for ; Mon, 3 Mar 2003 10:50:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05449 for ; Mon, 3 Mar 2003 11:50:22 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:50:17 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:50:16 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:50:16 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 3 Mar 2003 18:50:16 Z Content-class: urn:content-classes:message Subject: RE: IPv6 WG Last Call on "Requirements for IPv6 prefix delegation" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Mar 2003 10:50:15 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C5D@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 WG Last Call on "Requirements for IPv6 prefix delegation" Thread-Index: AcLhsChGr8EBy9cVSgGr+/XiGWJxhwAAIAoQ From: "Michel Py" To: "Margaret Wasserman" , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h23IoK7f014629 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret / Shin / Ralph, > Margaret Wasserman > This is an IPv6 working group last call for comments on > submitting the following document for consideration as an > Informational RFC: > Title: Requirements for IPv6 prefix delegation > 4.1 Number and Length of Delegated Prefixed > The prefix delegation mechanism SHOULD allow for delegation > of prefixes of length /48, /64 and other lengths, and SHOULD > allow for delegation of more than one prefix to the customer. This is too vague IMHO; either: a) s\and other lengths\and other lengths shorter than /64 or b) s\and other lengths\and other lengths between /48 and /64 b) is more restrictive, although it could be argued that the very few organizations that will be assigned a prefix shorter than /48 will likely not use prefix delegation and break it up in multiple /48s anyway. - IMHO, there should be a non-normative reference to RFC3177 in 1.Introduction, as it would clarify the expectation that customers will be assigned a /48 IPv6 address prefix. - If convenient, a normative reference to the soon-to-be-published-any-day-now addr-arch-3.11 would be useful to complete the paper trail. - 4.7 Layer 2 Considerations. "Layer 2" could be confusing as there is no reference to the model. The model I guess you have in mind is fine by me as I have long lobbied for using a well-defined de-jure model instead of a blurry de-facto model for documentation purposes, but I hear that it is a capital sin to use this model within the IETF. Michel. -------------------------------------------------------------------- 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 Mar 3 19:28:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h243Sx7f019368; Mon, 3 Mar 2003 19:28:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h243Swck019367; Mon, 3 Mar 2003 19:28:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h243St7f019357 for ; Mon, 3 Mar 2003 19:28:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h243T4xi005822 for ; Mon, 3 Mar 2003 19:29:04 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25523 for ; Mon, 3 Mar 2003 19:28:57 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 03:28:56 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 03:28:55 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 03:28:54 Z Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 03:28:54 Z Received: from philsmit-w2k01.cisco.com (ssh-syd-1.cisco.com [64.104.193.37]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h243SQP8013627; Mon, 3 Mar 2003 19:28:27 -0800 (PST) Message-Id: <5.1.0.14.2.20030304131358.04ab7758@localhost> X-Sender: philip@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Mar 2003 13:26:42 +1000 To: "Michel Py" From: Philip Smith Subject: RE: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Cc: , , In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C4D@server2000.arneill-py .sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Michel, We are simply documenting existing APNIC policy in this draft. Having a large block to help document multihoming examples makes sense, but I don't see anything wrong with the example you say is a problem. Yes, operationally it might be a bit odd, but for documentation? Would there be confusion in the minds of people who are reading the documentation? I've used various parts of 220/8 address space for my IPv4 multihoming examples (because there is no such prefix in IPv4), and no one has ever complained about me taking a /20 (the RIR minimum allocation) and splitting into lots of pieces to demonstrate multihoming. But that's my experience... Anyway, if folks think that a larger address block should be proposed for documentation, let us know what the number should be and why it should be so, and I will be more than happy to propose it to the next APNIC Open Policy Meeting as an amendment to the existing policy. philip -- At 20:29 27/02/2003 -0800, Michel Py wrote: > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > Title : IPv6 Documentation Address > > Author(s) : G. Huston, A. Lord, P. Smith > > Filename : draft-huston-ipv6-documentation-prefix-00.txt > >This text is a good beginning, but as I mentioned earlier a single /32 >is not enough to document multihoming scenarios. > >A site receives connectivity from 3 LIRs; the site is assigned three >/48s. >It would be confusing to make these three /48 part of the same /32 as >lots of people would assume that a LIR gets a /32 as it is current >policy. > >Example: >Prefix assigned by LIR 1: 2001:0DB8:1234::/48 >Prefix assigned by LIR 2: 2001:0DB8:5678::/48 >Prefix assigned by LIR 3: 2001:0DB8:ABCD::/48 >Something does not register here, as people might assume that LIRs 1,2 >and 3 are tier-2 or -3 LIRs that all get transit from a bigger tier-1 >LIR that has been allocated 2001:0DB8::/32 (which defeats half of the >reasons to multihome). > >The purpose of the documentation prefix is double: >1. Avoid using addresses that could be assigned to a site. >2. Avoid using things such as: >Prefix assigned by LIR 1: 2001:x:y::/48 >Prefix assigned by LIR 2: 2001:a:b::/48 >Prefix assigned by LIR 3: 2001:c:d::/48 > >Editorial: including the email addresses of the authors in the text >would not hurt anyone. > >Michel. -------------------------------------------------------------------- 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 Mar 3 20:50:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h244oX7f019785; Mon, 3 Mar 2003 20:50:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h244oXht019784; Mon, 3 Mar 2003 20:50:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h244oT7f019776 for ; Mon, 3 Mar 2003 20:50:29 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h244ocxi020444 for ; Mon, 3 Mar 2003 20:50:38 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28216 for ; Mon, 3 Mar 2003 20:50:33 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 04:50:32 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 04:50:32 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 04:50:31 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 04:50:31 Z Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Date: Mon, 3 Mar 2003 20:50:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C5F@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Thread-Index: AcLh/i4nNv0/Tqb9TiaZBNLnhR/VsQAA1bgQ From: "Michel Py" To: "Philip Smith" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h244oU7f019777 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Philip, > Philip Smith wrote: > We are simply documenting existing APNIC policy in this draft. I understand, and documenting it is nice _and_ necessary; until a few days ago I was not aware of that prefix (and I would bet that half of this mailing list was not either). To make myself perfectly clear I would rather see this doc shipped with that one /32 now and be upgraded later if other documentation prefixes pop up vs. waiting for more prefixes to be assigned to documentation. In other words: documenting APNIC policy is nice, APNIC deserves kudos for assigning a /32 to the purpose of documentation prefixes, and your draft should, if possible, go further than what is already there but ship as-is if nothing new is on the horizon. > Having a large block to help document multihoming examples makes > sense, but I don't see anything wrong with the example you say is > a problem. Yes, operationally it might be a bit odd, but for > documentation? Would there be confusion in the minds of people who > are reading the documentation? There are two aspects to this: 1. This is what I'm worried about, yes. The /32 LIR pseudo boundary is way too convenient to assume that people won't assume it's there. The sad truth is that more than 50% of "engineers" that do IPv4 assume that a subnet mask is always 255.255.255.0; we have to understand the fact that the same people will assume: /64 subnet prefix, /48 site prefix, /32 LIR prefix. I know and so do you that the ":" is not a boundary, but in people's minds it will be one. A /32 in the IPv6 space is not even a drop in the sea. Two /32s are still a drop in the sea. I fully agree with conservation principles, but the fact of the matter is that I already have multiple /48s for my home setup, so the argument about allocating a few /32s instead of a single one is moot. In other words: it is my evaluation that a _few_ /32 prefixes, instead of a single one, are a worthy trade-off between "waste" of IPv6 address space and elegance and "feeling realistic" documentation. 2. Documentation is one thing, lab-ing a scenario is quite another. Call me sick if you want, but when I do a 20-router 3-LIR simulation lab, I do configure it the way it should be in the real world, which is that each LIR gets a /32 that is an aggregate of the IGP's space, each ptp link gets a /64, each "site" (thanks to the guy that invented the loopback interface) a /48, etc. My point here is that I am currently hijacking Global Unicast space for lab purposes, and if a single /32 is what I get for lab I will continue to do so. The point is not why I need a /29 to lab a scenario; I can fit it in a /48 if need be. The point is that a good documentation and a good lab a) does not hijack public space and b) looks like the real McCoy with the addresses being different, not the prefixes. > Anyway, if folks think that a larger address block should be > proposed for documentation, let us know what the number should > be and why it should be so, and I will be more than happy to > propose it to the next APNIC Open Policy Meeting as an > amendment to the existing policy. IMHO, an additional /32 from the APNIC space, plus two from the ARIN space and two from the RIPE space (all of them preferably not contiguous) would be good. Two /32s from an IETF request directly to the IANA would look good too, but given the time Marc Blanchet's draft has been lost in space I will not loose sleep over them. Michel. -------------------------------------------------------------------- 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 Mar 3 23:08:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2478w7f020275; Mon, 3 Mar 2003 23:08:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2478wGf020274; Mon, 3 Mar 2003 23:08:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2478s7f020267 for ; Mon, 3 Mar 2003 23:08:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24793J8014609 for ; Mon, 3 Mar 2003 23:09:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01717 for ; Tue, 4 Mar 2003 00:08:57 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:08:53 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:06:56 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:08:53 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:08:53 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA22954; Mon, 3 Mar 2003 23:08:49 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2478mL19613; Mon, 3 Mar 2003 23:08:48 -0800 X-mProtect: <200303040708> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (209.157.142.164, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEpiv3g; Mon, 03 Mar 2003 23:08:47 PST Message-Id: <4.3.2.7.2.20030303230427.032cac68@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Mar 2003 23:08:21 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: DRAFT: Agenda Announcement Cc: hinden@iprg.nokia.com, Margaret Wasserman Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 working group has two session at the San Francisco IETF meeting. They are: MONDAY, March 17, 2003, 1930-2200 THURSDAY, March 20, 2003, 0900-1130 There are several important topics to which we will devote significant meeting time. - Node Requirements - Prefix Delegation - Site-Local Usage o Impact of Site-Local draft o Moderate Use Case draft - MIB Updates Please send us requests for agenda items. We will be giving priority to the above topics, but will fit other things in as time allows. For this we will give preference to current working group documents and last to status reports. Thanks, Bob Hinden and Margaret Wasserman -------------------------------------------------------------------- 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 Mar 3 23:49:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h247nl7f020727; Mon, 3 Mar 2003 23:49:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h247nkoe020726; Mon, 3 Mar 2003 23:49:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h247nh7f020719 for ; Mon, 3 Mar 2003 23:49:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h247npxi021589 for ; Mon, 3 Mar 2003 23:49:51 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA17427 for ; Tue, 4 Mar 2003 00:49:44 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:49:42 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:49:41 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:49:41 Z Received: from dhcp-168-17-124.autonomica.se ([192.71.80.74] [192.71.80.74]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 07:49:41 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h247ojif012131; Tue, 4 Mar 2003 08:50:46 +0100 (CET) Date: Tue, 4 Mar 2003 08:50:44 +0100 Subject: Re: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Michel Py" , , , To: Philip Smith From: Kurt Erik Lindqvist In-Reply-To: <5.1.0.14.2.20030304131358.04ab7758@localhost> Message-Id: <012019EE-4E16-11D7-ADF5-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Having a large block to help document multihoming examples makes > sense, but I don't see anything wrong with the example you say is a > problem. Yes, operationally it might be a bit odd, but for > documentation? Would there be confusion in the minds of people who are > reading the documentation? I've used various parts of 220/8 address > space for my IPv4 multihoming examples (because there is no such > prefix in IPv4), and no one has ever complained about me taking a /20 > (the RIR minimum allocation) and splitting into lots of pieces to > demonstrate multihoming. But that's my experience... > > Anyway, if folks think that a larger address block should be proposed > for documentation, let us know what the number should be and why it > should be so, and I will be more than happy to propose it to the next > APNIC Open Policy Meeting as an amendment to the existing policy. > I agree with Philip, I fail to see the need for prefixes from each LIR for documenting. We have managed without this in IPv4 so far and I think we can in IPv6. Next step would then be to require a prefix from each RIR.... - kurtis - -------------------------------------------------------------------- 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 Mar 4 04:30:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24CUw7f023411; Tue, 4 Mar 2003 04:30:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24CUwhO023410; Tue, 4 Mar 2003 04:30:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24CUn7f023398 for ; Tue, 4 Mar 2003 04:30:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24CUwJ8009045 for ; Tue, 4 Mar 2003 04:30:58 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25734 for ; Tue, 4 Mar 2003 05:30:53 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:30:52 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:30:45 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:30:45 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:30:45 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14682; Tue, 4 Mar 2003 07:28:42 -0500 (EST) Message-Id: <200303041228.HAA14682@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Date: Tue, 04 Mar 2003 07:28:42 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Global Unicast Address Format Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-unicast-aggr-v2-02.txt Pages : 5 Date : 2003-3-3 RFC2374 'An IPv6 Aggregatable Global Unicast Address Format' defined an IPv6 address allocation structure that includes TLA (Top Level Aggregator) and NLA (Next Level Aggregator). This document replaces RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ipv6-unicast-aggr-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-3-3144840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-unicast-aggr-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144840.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 Tue Mar 4 04:31:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24CVK7f023428; Tue, 4 Mar 2003 04:31:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24CVJ4P023427; Tue, 4 Mar 2003 04:31:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24CVA7f023413 for ; Tue, 4 Mar 2003 04:31:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24CVJxi013830 for ; Tue, 4 Mar 2003 04:31:19 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24378 for ; Tue, 4 Mar 2003 05:31:14 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:31:13 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:28:42 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:30:40 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 12:30:40 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14662; Tue, 4 Mar 2003 07:28:37 -0500 (EST) Message-Id: <200303041228.HAA14662@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-flow-label-05.txt Date: Tue, 04 Mar 2003 07:28:37 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-05.txt Pages : 8 Date : 2003-3-3 This document specifies the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, the requirements for IPv6 nodes forwarding labeled packets, and the requirements for flow state establishment methods. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ipv6-flow-label-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-flow-label-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-3-3144832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-3144832.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 Tue Mar 4 06:38:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24Ecq7f024891; Tue, 4 Mar 2003 06:38:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24Ecqe8024890; Tue, 4 Mar 2003 06:38:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24Ecn7f024883 for ; Tue, 4 Mar 2003 06:38:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24Ecwxi010509 for ; Tue, 4 Mar 2003 06:38:58 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02473 for ; Tue, 4 Mar 2003 07:38:52 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:38:47 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:38:47 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:38:47 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:38:46 Z Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Mar 2003 06:38:46 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045472@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Thread-Index: AcLiU8S6lF71oBA4Szy1RRa+BrH52wAB82tg From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h24Ecn7f024884 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I hear the fedex truck already. > Subject: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the IP Version 6 Working Group > Working Group of the IETF. > Title: IPv6 Global Unicast Address Format Michel. -------------------------------------------------------------------- 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 Mar 4 06:59:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24ExY7f025120; Tue, 4 Mar 2003 06:59:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24ExXe4025119; Tue, 4 Mar 2003 06:59:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24ExU7f025112 for ; Tue, 4 Mar 2003 06:59:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24ExdJ8005367 for ; Tue, 4 Mar 2003 06:59:39 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21744 for ; Tue, 4 Mar 2003 06:59:33 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:59:32 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:57:34 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:59:32 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 14:59:31 Z Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Date: Tue, 4 Mar 2003 06:59:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C61@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-huston-ipv6-documentation-prefix-00.txt Thread-Index: AcLiRan48UFuxnLtR96oNLv5Jejh1wAFmNVQ From: "Michel Py" To: "Geoff Huston" , "Philip Smith" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h24ExU7f025113 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Geoff Huston wrote: > Does that mean want to propose to use 2001:D0C0::/32 as well? Gee, even I could remember that one! 2001:D0C::/32 would be even nicer, there are number of other alternatives such as 2001:2D0C::/32 and 2001:4D0C::/32. Michel. -------------------------------------------------------------------- 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 Mar 4 09:49:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24Hnm7f027100; Tue, 4 Mar 2003 09:49:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24HnmbG027099; Tue, 4 Mar 2003 09:49:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24Hnj7f027092 for ; Tue, 4 Mar 2003 09:49:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24Hnsxi002182 for ; Tue, 4 Mar 2003 09:49:54 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22266 for ; Tue, 4 Mar 2003 10:49:48 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 17:49:47 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 17:49:47 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 17:49:47 Z Received: from TheWorld.com ([199.172.62.104] [199.172.62.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 17:49:47 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id MAA17452; Tue, 4 Mar 2003 12:49:35 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id MAA3334293; Tue, 4 Mar 2003 12:49:34 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 4 Mar 2003 12:49:34 -0500 From: Quality Quorum To: Bob Hinden & Margaret Wasserman cc: ipng@sunroof.eng.sun.com, Margaret Wasserman Subject: Re: DRAFT: Agenda Announcement In-Reply-To: <4.3.2.7.2.20030303230427.032cac68@mailhost.iprg.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 3 Mar 2003, Bob Hinden & Margaret Wasserman wrote: > The IPv6 working group has two session at the San Francisco IETF > meeting. They are: > > MONDAY, March 17, 2003, 1930-2200 > THURSDAY, March 20, 2003, 0900-1130 > > There are several important topics to which we will devote significant > meeting time. > > - Node Requirements > - Prefix Delegation > - Site-Local Usage > o Impact of Site-Local draft > o Moderate Use Case draft > - MIB Updates > > Please send us requests for agenda items. We will be giving priority to > the above topics, but will fit other things in as time allows. For this we > will give preference to current working group documents and last to status > reports. I am going to submit another draft for site-locals, it is being reviewed internally, I hope to do it today. > > Thanks, > Bob Hinden and Margaret Wasserman > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 4 10:41:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24If07f027587; Tue, 4 Mar 2003 10:41:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24If0cR027586; Tue, 4 Mar 2003 10:41:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24Iev7f027579 for ; Tue, 4 Mar 2003 10:40:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24If6xi020331 for ; Tue, 4 Mar 2003 10:41:06 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05849 for ; Tue, 4 Mar 2003 10:41:01 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:40:36 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:40:35 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:40:35 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:40:35 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA16083; Tue, 4 Mar 2003 10:40:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h24IeXI27636; Tue, 4 Mar 2003 10:40:33 -0800 X-mProtect: <200303041840> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3935co; Tue, 04 Mar 2003 10:40:31 PST Message-Id: <4.3.2.7.2.20030304102621.02879840@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Mar 2003 10:40:23 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a one week IPv6 working group last call for comments on advancing the following document as a Proposed Standard: Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-05.txt Pages : 8 Date : 2003-3-3 The chairs belive this draft represents the consensus of the working group and resolves issues raised during and subsequent to the working group last call. However given the time that has elapsed we think a short working group last call is desirable to verify the consensus before forwarding the document to the IESG. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on 11 March 2003. Bob Hinden / Margaret Wasserman -------------------------------------------------------------------- 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 Mar 4 10:58:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24IwR7f028113; Tue, 4 Mar 2003 10:58:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24IwRSl028112; Tue, 4 Mar 2003 10:58:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24IwO7f028105 for ; Tue, 4 Mar 2003 10:58:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24IwXJ8019994 for ; Tue, 4 Mar 2003 10:58:33 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03006 for ; Tue, 4 Mar 2003 11:58:27 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:58:27 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:58:27 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:58:26 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 18:58:26 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA16631; Tue, 4 Mar 2003 10:58:25 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h24IwOQ09541; Tue, 4 Mar 2003 10:58:24 -0800 X-mProtect: <200303041858> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQf6vVn; Tue, 04 Mar 2003 10:58:23 PST Message-Id: <4.3.2.7.2.20030304104158.02876210@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Mar 2003 10:58:21 -0800 To: Margaret Wasserman From: Bob Hinden Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200303041228.HAA14682@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the new draft resolves issues raised during the last call. Changes to the document include: - Generalize the scope of the document to cover more than the 2000::/3 prefix. This includes changing the title and introduction text. - Added a new section that describes in more detail why the TLA/NLA structure is being made historic. - Including an example of the address format that is consistent with the recommendations in RFC3177. - Added Erik Nordmark as an author (note this is not shown in the ID announcement). - Clarified normative and non-normative references. - Various small improvements to the text. I think the consensus of the discussion was to advance this document as in Informational RFC instead of to Proposed Standard. I believe it is now ready to be sent to the IESG. Bob At 04:28 AM 3/4/2003, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Version 6 Working Group Working Group >of the IETF. > > Title : IPv6 Global Unicast Address Format > Author(s) : R. Hinden, S. Deering > Filename : draft-ietf-ipv6-unicast-aggr-v2-02.txt > Pages : 5 > Date : 2003-3-3 > >RFC2374 'An IPv6 Aggregatable Global Unicast Address Format' defined >an IPv6 address allocation structure that includes TLA (Top Level >Aggregator) and NLA (Next Level Aggregator). This document replaces >RFC2374, and makes RFC 2374 and the TLA/NLA structure historic. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also 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-ipv6-unicast-aggr-v2-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt". > >NOTE: The mail server at ietf.org 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. >Content-Type: text/plain >Content-ID: <2003-3-3144840.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-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 Tue Mar 4 11:30:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24JUP7f028615; Tue, 4 Mar 2003 11:30:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24JUOLI028614; Tue, 4 Mar 2003 11:30:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24JUL7f028607 for ; Tue, 4 Mar 2003 11:30:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24JUUJ8002086 for ; Tue, 4 Mar 2003 11:30:30 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25699 for ; Tue, 4 Mar 2003 12:30:24 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 19:30:24 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 19:30:23 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 19:30:23 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 19:30:23 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h24JUCY32555; Tue, 4 Mar 2003 21:30:12 +0200 Date: Tue, 4 Mar 2003 21:30:11 +0200 (EET) From: Pekka Savola To: Bob Hinden cc: Margaret Wasserman , Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: <4.3.2.7.2.20030304104158.02876210@mailhost.iprg.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Mar 2003, Bob Hinden wrote: > I think the new draft resolves issues raised during the last call. Changes > to the document include: > > - Generalize the scope of the document to cover more than the 2000::/3 > prefix. This includes changing the title and introduction text. > - Added a new section that describes in more detail why the TLA/NLA structure > is being made historic. > - Including an example of the address format that is consistent with > the recommendations in RFC3177. > - Added Erik Nordmark as an author (note this is not shown in the > ID announcement). > - Clarified normative and non-normative references. > - Various small improvements to the text. > > I think the consensus of the discussion was to advance this document as in > Informational RFC instead of to Proposed Standard. I believe it is now > ready to be sent to the IESG. One substantial point I'd like to see more discussion on is whether folks feel that "Address Format" section, mainly restating what addr-arch-v3-11 says on 64 bit IID's, seems like the right thing to do in this document? I think this point was brought up by at least Thomas Narten and others, but I don't remember whether a closure was reached. So, I believe everything starting from: [ARCH] also requires that all unicast addresses, except those that start with binary value 000, have Interface IDs that are 64 bits long and to be constructed in Modified EUI-64 format. The format of global unicast address in this case is: [...] should be removed, if not the whole section. I can live with this but IMO putting 64-bit-interface-ID thing which is rather controversial still in too many documents seems like something to be careful about. How do others feel? Below are a few very minor editorial nits: INTERNET-DRAFT R. Hinden, Nokia February 26, 2003 S. Deering, Cisco E. Nordmark, Sun ==> the header should probably say IPv6 working group. unassigned parts of the IPv6 address space to the purpose of Global Unicast as well. ==> "to the purpose of" ? Sounds awkward, especially "to"? ==> "Global Unicast" capitalized looks funny, as if it was somehow a special term. Non-Normative ==> better named Informative, I guess? [ARCH] Hinden, R., "IP Version 6 Addressing Architecture", Internet Draft, , October 2002. ==> Forgot Steve from the author list :-) 6.0 Security Considerations ==> I believe Sec Cons is typically up, before references but YMMV. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 4 12:57:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24Kv87f029700; Tue, 4 Mar 2003 12:57:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24Kv7Z7029699; Tue, 4 Mar 2003 12:57:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24Kv47f029692 for ; Tue, 4 Mar 2003 12:57:04 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24KvCxi010208 for ; Tue, 4 Mar 2003 12:57:13 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24601 for ; Tue, 4 Mar 2003 12:57:07 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 20:57:06 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 20:55:07 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 20:57:05 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 20:57:05 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h24Kv1v00675; Tue, 4 Mar 2003 22:57:01 +0200 Date: Tue, 4 Mar 2003 22:57:00 +0200 (EET) From: Pekka Savola To: Bob Hinden & Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" In-Reply-To: <4.3.2.7.2.20030304102621.02879840@mailhost.iprg.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Mar 2003, Bob Hinden & Margaret Wasserman wrote: > This is a one week IPv6 working group last call for comments on advancing > the following document as a Proposed Standard: > > Title : IPv6 Flow Label Specification > Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering > Filename : draft-ietf-ipv6-flow-label-05.txt > Pages : 8 > Date : 2003-3-3 > > The chairs belive this draft represents the consensus of the working group > and resolves issues raised during and subsequent to the working group last > call. However given the time that has elapsed we think a short working > group last call is desirable to verify the consensus before forwarding the > document to the IESG. [note: I had already written this message once but accidentally cancelled the message -- hope I don't forget anything] In summary, I don't believe the doc is ready to be sent to the IESG. There are a few major issues to be worked out yet, the last of the the most important. Comments below. substantial: ------------ The 3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used. ==> this might require some extra analysis somewhere (not in that particular place, I think). In particular, this seems to say that once this is published people can happily move to using the three-tuple classification. The reality is probably quite different, and one must also consider the big portion of nodes which do not mark the flows. A possible fix would be to tone down "enable" (e.g. "make xxx possible") and add some minor tweaking. To enable applications and transport protocols to define what packets constitute a flow, the source node MUST provide means for the applications and transport protocols to specify the Flow Label values to be used with their flows. ==> this requirement seems unacceptable at the moment. This clearly requires (at least) de-facto API so applications could set Flow Label values -- and as such does not exist. If it did (and I believe there's work in progress), there would *have to be* a normative reference to it). So, clearly a MUST seems to a big no-no. A source node MUST ensure that it does not reuse Flow Label values it is currently using or has recently used when creating new flows. Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow. ==> so, if I make create a raw socket, manually fiddle in the flow label value which was previously used, and send the packet, the operating system kernel should hijack it and prevent it from going out? Get real. Perhaps s/reuse/unintentionally reuse/, or some other rewording? To enable co-existence of different methods in IPv6 nodes, the methods MUST meet the following basic requirements: ==> this and the following points seem a little oddly placed in this memo: they seem out-of-place, as the rest of the memo seems to concentrate on entirely different issues. Personally I view specifying how source nodes should label flows one thing, and the rest entirely another. But I can live with these, even though I think they're more fit to a non-standards track document. 5.1 Theft and Denial of Service ==> this section mainly deals with issues relating to forging all of the source,destination,label three-tuple (exception is the last paragraph, which deals with a trusted-node-but-untrusted-user/application case), which protects mainly against a DoS attack (resource depletion). This seems to overlook the most important part: the typical model today is that operators perform differentiation of flows *themselves*: this document proposes to shift that, *over an administrative boundary*, to the source nodes, which suddenly become trusted to do the right thing. This would be equivalent to replacing network ingress filtering (to drop packets with forged source addresses) to a requirement for nodes to allow out only packets which include their own source address. Needless to say this seems to indicate a major oversight of the security/operational reality. I'd be very surprised if this was not pushed back in the IESG unless this caveat is very explicitly documented. semi-editorial -------------- Nodes keeping dynamic flow state MUST NOT assume packets arriving 120 seconds or more after the previous packet of a flow still belong to the same flow, unless a flow state establishment method in use defines a longer flow state lifetime or the flow state has been explicitly refreshed within the lifetime duration. ==> this is a way too sentence, 5 lines, and constructed in with a negative: "MUST NOT blahblah, unless foofoo". You really have to read that a couple of times to understand what it's trying to say. I'd strongly urge to reword and simplify. editorial --------- If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet. ==> reword: "providing .. treatment" seems to sound awkward in the case of "receiving a packet" (ie. in the case of end-node, not router). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 4 15:40:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24NeS7f000624; Tue, 4 Mar 2003 15:40:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h24NeS72000623; Tue, 4 Mar 2003 15:40:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h24NeO7f000616 for ; Tue, 4 Mar 2003 15:40:24 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h24NeYvx018872 for ; Tue, 4 Mar 2003 15:40:34 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09006 for ; Tue, 4 Mar 2003 15:40:28 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 23:40:28 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 23:40:28 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 23:40:27 Z Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 4 Mar 2003 23:40:27 Z Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h24NeLZ08357; Tue, 4 Mar 2003 15:40:21 -0800 (PST) Message-Id: <200303042340.h24NeLZ08357@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3484 on Default Address Selection for Internet Protocol version 6 (IPv6) Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 04 Mar 2003 15:40:21 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3484 Title: Default Address Selection for Internet Protocol version 6 (IPv6) Author(s): R. Draves Status: Standards Track Date: February 2003 Mailbox: richdr@microsoft.com Pages: 24 Characters: 55076 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-default-addr-select-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3484.txt This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. This document is a product of the IP Version 6 Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030304153812.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3484 --OtherAccess Content-Type: Message/External-body; name="rfc3484.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030304153812.RFC@RFC-EDITOR.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 Tue Mar 4 16:02:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2502J7f000905; Tue, 4 Mar 2003 16:02:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2502JaQ000904; Tue, 4 Mar 2003 16:02:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2502G7f000897 for ; Tue, 4 Mar 2003 16:02:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2502Pvx025837 for ; Tue, 4 Mar 2003 16:02:25 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25368 for ; Tue, 4 Mar 2003 16:02:19 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 00:02:09 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 00:02:07 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 00:02:07 Z Received: from TheWorld.com ([199.172.62.104] [199.172.62.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 00:02:06 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id TAA13566; Tue, 4 Mar 2003 19:02:02 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id TAA3488212; Tue, 4 Mar 2003 19:01:58 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 4 Mar 2003 19:01:57 -0500 From: Quality Quorum To: Pekka Savola cc: Bob Hinden , Margaret Wasserman , Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One substantial point I'd like to see more discussion on is whether folks > feel that "Address Format" section, mainly restating what addr-arch-v3-11 > says on 64 bit IID's, seems like the right thing to do in this document? > > I think this point was brought up by at least Thomas Narten and others, > but I don't remember whether a closure was reached. > > So, I believe everything starting from: > > [ARCH] also requires that all unicast addresses, except those that > start with binary value 000, have Interface IDs that are 64 bits long > and to be constructed in Modified EUI-64 format. The format of > global unicast address in this case is: > [...] > > should be removed, if not the whole section. > > I can live with this but IMO putting 64-bit-interface-ID thing which is > rather controversial still in too many documents seems like something to > be careful about. The problem here is software implementation of longest prefix match. Up to this point it was limited to a few TLAs with 48 bits which was quite doable in software, this draft expands it to 61 and you are proposing 125, which is well beyond capabilities of software based lookups. I do not see anything specifically wrong with this approach if a complete enterprise router replacement is a stated goal of IPv6. If not then we have to address the issue of software based implementations somehow. Again, it may be a way to go, but frankly I am in a little shock - after many years of planing for various hierarchical partitions to find myself back in CIDR without borders environment and all of it in a matter of days. > Pekka Savola "You each name yourselves king, yet the Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 4 20:26:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h254Qe7f004739; Tue, 4 Mar 2003 20:26:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h254QehP004738; Tue, 4 Mar 2003 20:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h254Qb7f004731 for ; Tue, 4 Mar 2003 20:26:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h254Qkvx014138 for ; Tue, 4 Mar 2003 20:26:46 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08802 for ; Tue, 4 Mar 2003 20:26:41 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 04:26:39 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 04:23:37 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 04:25:36 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 04:25:35 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h254PHU03445; Wed, 5 Mar 2003 06:25:17 +0200 Date: Wed, 5 Mar 2003 06:25:16 +0200 (EET) From: Pekka Savola To: Quality Quorum cc: Bob Hinden , Margaret Wasserman , Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Mar 2003, Quality Quorum wrote: > The problem here is software implementation of longest prefix match. > Up to this point it was limited to a few TLAs with 48 bits which was > quite doable in software, this draft expands it to 61 Note that "this" draft does not do it, it has been already done in addr-arch-v3, which has been approved by IESG/IAB for publication to Proposed Standard. > and you are > proposing 125, which is well beyond capabilities of software based > lookups. "well beyond capabilities of software based lookups" seems to be clearly false: I've run IPv6 test on Linux / BSD-based systems, which do have exactly that and have obtained gigabit-grade results, the same as with IPv4. Perhaps that applies in a very specific scenario of sw lookups only. Btw, it's 64 and 128, respectively: you seem to be doing exactly what's forbidden, glueing 2000::/3 in the implementation -- or do you do 48/64/128-bit lookup for non-2000::/3 routes? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 4 22:36:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h256ab7f005113; Tue, 4 Mar 2003 22:36:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h256abuu005112; Tue, 4 Mar 2003 22:36:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h256aY7f005105 for ; Tue, 4 Mar 2003 22:36:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h256ahvx009651 for ; Tue, 4 Mar 2003 22:36:43 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04759 for ; Tue, 4 Mar 2003 23:36:37 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:36:37 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:36:37 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:36:37 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:36:36 Z Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Date: Tue, 4 Mar 2003 22:36:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C6D@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Thread-Index: AcLihLVRv5X3Qyx9Sp+Dgv+qwCc4gAAXCscg From: "Michel Py" To: "Pekka Savola" , "Bob Hinden" Cc: "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h256aY7f005106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > So, I believe everything starting from: > [ARCH] also requires that all unicast addresses, except those > that start with binary value 000, have Interface IDs that are > 64 bits long and to be constructed in Modified EUI-64 format. > The format of global unicast address in this case is: [...] > should be removed, if not the whole section. I think it should be kept. There is a logical progression in section 3.0, from n|m|128-n-m to n|64-n|64 to 3|45|16|64. Only the last one is an example, but the progression from the generic v6 format seems very logical to me and examples are generally good. Michel. -------------------------------------------------------------------- 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 Mar 4 22:50:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h256ob7f005332; Tue, 4 Mar 2003 22:50:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h256obwv005331; Tue, 4 Mar 2003 22:50:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h256oX7f005324 for ; Tue, 4 Mar 2003 22:50:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h256ogvx012640 for ; Tue, 4 Mar 2003 22:50:42 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24120 for ; Tue, 4 Mar 2003 23:50:37 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:50:35 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:50:25 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:50:25 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 06:50:25 Z Content-class: urn:content-classes:message Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Date: Tue, 4 Mar 2003 22:50:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C6E@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Thread-Index: AcLikV1MTMCD3SsPQVK29a+nQDbW7wAUJQNg From: "Michel Py" To: "Bob Hinden & Margaret Wasserman" , "Brian Carpenter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h256oX7f005325 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob / Margaret / Brian, > Bob Hinden & Margaret Wasserman wrote: > This is a one week IPv6 working group last call for comments > on advancing the following document as a Proposed Standard: > Title: IPv6 Flow Label Specification > Author(s): J. Rajahalme, A. Conta, B. Carpenter, S. Deering The parts that I cared about have been preserved; it's a go for me. > The chairs belive this draft represents the consensus of the > working group and resolves issues raised during and subsequent > to the working group last call. However given the time that > has elapsed we think a short working group last call is > desirable to verify the consensus before forwarding the > document to the IESG. Note: I have not been following this closely, so this might have been addressed already. If my memory is correct during one of the Atlanta meetings one of the authors (Brian Carpenter) had some concerns about the then-current text. Forgive me if I have missed it, I would like to hear from Brian if the concerns he had at the time have been addressed. The reason I am specifically interested in Brian's comments is because about the same time we were discussing the interactions between MHAP and flow control. Thanks Michel. -------------------------------------------------------------------- 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 Mar 5 07:08:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25F8Y7f006462; Wed, 5 Mar 2003 07:08:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25F8YVU006461; Wed, 5 Mar 2003 07:08:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25F8V7f006454 for ; Wed, 5 Mar 2003 07:08:31 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25F8dYt029067 for ; Wed, 5 Mar 2003 07:08:39 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12635 for ; Wed, 5 Mar 2003 07:08:33 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:08:11 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:07:49 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:07:49 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:07:48 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h25F7gh07181; Wed, 5 Mar 2003 17:07:42 +0200 Date: Wed, 5 Mar 2003 17:07:42 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 WG Last Call on "Requirements for IPv6 prefix delegation" In-Reply-To: <5.1.0.14.2.20030303130201.035ac838@mail.windriver.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 3 Mar 2003, Margaret Wasserman wrote: > Title : Requirements for IPv6 prefix delegation > Author(s) : S. Miyakawa, R. Droms > Filename : draft-ietf-ipv6-prefix-delegation-requirement-01.txt > Pages : 5 > Date : 2003-2-28 > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end two > weeks from today on March 17, 2003. I've re-read the document, and I believe it is not yet ready to be sent to the IESG. Comments below. substantial/semi-editorial: --------------------------- ==> first issue: the draft contains RFC2119 upper-case keywords; I'm not sure how useful these are in a requirements document (compared to a prefix delegation protocol document), as you can't really honestly say that something would be "mandatory to implement for interoperability" etc. So, I'd be interested to hear whether others see this as a potential problem, and whether they should be changed. 4. Requirements for Prefix Delegation The purpose of the prefix delegation mechanism is to communicate prefixes to the CPE automatically. ==> further than that, is how the CPE handles required prefixes in scope? ==> in any case this should be reworded a bit, at least mention prefix lifetimes. (Ie., it's not just "delegate and forget", right?) 4.1 Number and Length of Delegated Prefixed The prefix delegation mechanism SHOULD allow for delegation of prefixes of length /48, /64 and other lengths, and SHOULD allow for delegation of more than one prefix to the customer. ==> maybe reword a bit and change this to a simpler format: The prefix delegation mechanism SHOULD allow for delegation of prefixes of length between /48 and /64, inclusive. Other lengths MAY be supported. The mechanism SHOULD allow for delegation of more than one prefix to the customer. 4.3 Automated Assignment The prefix delegation mechanism SHOULD allow for long-lived pre- assignment of one or more prefix(es) to a customer and for automated, possibly short-lived assignment of a prefix to a customer on demand. ==> this section seems mostly redundant, as the requirement for multiple prefixes was already listed, so the title should change and some rewording happen. This includes two "new" components, "Different Prefix-Specific Properties" (ie. ability to request short lifetimes for a set of prefixes, and long for other -- or at least have them separated), or on the prefix delegation mechanism itself ("manual" vs. automatic") which seems like a non-goal in requirements doc. Additionally, "on-demand" feature seems like a trivial requirement, and more to ISPs' operations than the protocol. Though, at the same time, it should be noted that now ISP would like to have a solution for Point-to-Point link which has own authentication mechanism first. PPP link with CHAP authentication is a good example. (Simulated) Ethernet and IEEE802.11 (wireless LAN) should be covered in near future, but they have low priority (just) for now. ==> does the working group agree on this priorization? I'm not sure if this is good for for a requirements document. 6. Security considerations Section 4.5 specifies security requirements for the prefix delegation mechanism. ==> I'm not sure if this would fly past security area AD's, at least :-). ==> in particular, it would be extremely useful to try to identify the threats associated with prefix delegation, and how the requirements set here correspond and meet those threats. editorial: ---------- ==> upper-case words in the titles and section headers widely deployed "always on" media as ADSL, and the expectation that ==> s/as/such as/ \------/ Illustration of ISP-customer network architecture ==> this is probably meant to be "figure text"; if so, it should be more clearly attached to it (alignment, no empty line, perhaps "Figure 1: xxx" or the like PE Provider edge device; the device at which the link to the customer site is terminated ==> , and which is connected to the provider's network infrastructure. (or something similar, otherwise PE/CPE definitions seem too much like circular definitions) CPE Customer provided equipment; the device at the customer site at which the link to the ISP is terminated ==> s/provided/premises/ !! The method SHOULD work on any layer 2 technologies. In other words, ==> s/ies/y/ References ==> there should probably be classified as normative references. In any case, refs need to be "split". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 5 07:12:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FCh7f006534; Wed, 5 Mar 2003 07:12:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FChTM006533; Wed, 5 Mar 2003 07:12:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FCe7f006526 for ; Wed, 5 Mar 2003 07:12:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25FCmYt029947 for ; Wed, 5 Mar 2003 07:12:48 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09870 for ; Wed, 5 Mar 2003 08:12:42 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:12:41 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:10:35 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:12:36 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:12:35 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h25FCLI07230; Wed, 5 Mar 2003 17:12:21 +0200 Date: Wed, 5 Mar 2003 17:12:21 +0200 (EET) From: Pekka Savola To: Michel Py cc: Bob Hinden , Margaret Wasserman , Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C6D@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Mar 2003, Michel Py wrote: > > Pekka Savola wrote: > > So, I believe everything starting from: > > [ARCH] also requires that all unicast addresses, except those > > that start with binary value 000, have Interface IDs that are > > 64 bits long and to be constructed in Modified EUI-64 format. > > The format of global unicast address in this case is: [...] > > should be removed, if not the whole section. > > I think it should be kept. There is a logical progression in section > 3.0, from n|m|128-n-m to n|64-n|64 to 3|45|16|64. Only the last one is > an example, but the progression from the generic v6 format seems very > logical to me and examples are generally good. A reference to the IESG/IAB recommendation -- or the RIPE policy document -- is clear enough, IMO. And this avoids the follow-up issue that it isn't IMO the good thing to have _IETF_ document decisions made by _RIR_'s. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 5 07:25:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FPk7f006949; Wed, 5 Mar 2003 07:25:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FPjmP006948; Wed, 5 Mar 2003 07:25:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FPg7f006941 for ; Wed, 5 Mar 2003 07:25:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25FPovx018461 for ; Wed, 5 Mar 2003 07:25:50 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00975 for ; Wed, 5 Mar 2003 08:25:45 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:25:44 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:23:43 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:25:44 Z Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:25:43 Z Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e34.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25FPg64189546 for ; Wed, 5 Mar 2003 10:25:42 -0500 Received: from cichlid.adsl.duke.edu ([9.65.209.0]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25FPf5B107542 for ; Wed, 5 Mar 2003 08:25:42 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h25FMxr06256 for ; Wed, 5 Mar 2003 10:22:59 -0500 Message-Id: <200303051522.h25FMxr06256@cichlid.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: Revised IPv6 charter and DNS discovery Date: Wed, 05 Mar 2003 10:22:59 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk note: AD hat on. Bob & Margaret have sent me a revised IPv6 charter that I have forwarded to the IESG/IAB for consideration. It is largely consistent with the charter that the WG has already seen and supported with one exception. "DNS discovery" is not included in the charter. I asked that this item be removed from the charter for several reasons: - If I were to take it to the IESG/IAB (who get to review all WG charters), I would expect to get strong pushback on including the DNS discovery work in the IPv6 WG. Reasons would include: - this is not IPv6-specific work, it should be done in a broader IETF context, e.g., where the DNS operational expertise resides such as in DNSOP. - why not just use DHC? I know that many are opposed to including DHC as part of the solution, but that view is not universally shared, understood, or agreed too. Especially outside of the IPv6 community. - what about the technical concerns that have been raised regarding the approach in the current draft? (See Erik Nordmark's presentation at the Yokohama meeting, for example.) IMO, there has been a lack of rigorous consideration of the issues that have been raised. Although I have heard the arguments coming from proponents of the DNS discovery work, I have not been strongly convinced. Moreover, I also have heard the arguments against the approach in the current document from others, and find their arguments to have merit as well. That puts me in the awkward position of arguing for a position within the IESG that the WG supports, but that I have concerns with and where I don't have strong answers for addressing those concerns. The issues here are not black-and-white. I see that there are multiple sides to the argument, but this group seems to have difficulty in having a technical discussion about those issues. It seems like the WG is to a large extent tired of this issue and just wants to have an RFC. - the dns discovery effort has dragged on for way too long (more than 2 years), and due in part part to the history, I have doubts about this WG being able to have a productive discussion on the topic anymore. Being very aware of ongoing discussions and concerns being discussed on, e.g., the problem-statement list, it is time to make some decisions and move on. One of those decision may just be that the idea of a quick-and-simple DNS discovery has missed its window of opportunity, and we just need to move on. - the current approach of interest assumes the use of SL addresses. Given the issues swirling around SL and to what degree the WG wants to encourage or limit their usage, I find it hard to believe that the current ID is a good way to go forward. It would seem odd to recommend this approach while simultaneously still having discussions about how much to discourage the usage of site-local addressing. - it is not clear to me there is really consensus for the current document at this point in time, whatever past concensus there might have been. Moreover, it's not clear how much support the selected approach has outside of the IPv6 community. This gets back to an earlier point about doing the work in consultation with the right experts. Where to go from here? If there is truly interest in continuing this work, it might make sense to engage the DNSOP WG to see what kind of interest there is there _for the problem statement_ before even discussing any particular approach. It might also make sense to host a BOF on either the narrow topic of DNS discovery or the broader topic of service discovery. Steve Deering posted a long note a while back on "serverless discovery" that I think was quite interesting, but much work needs to be done to flesh that out, assuming there is interest in doing so. Finally, there is always DHC (the IESG approved DHCPv6 as a PS at the end of 2002), so the IETF _does_ have a recommended approach -- it's just one that some people don't like. 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 Wed Mar 5 07:29:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FTQ7f007042; Wed, 5 Mar 2003 07:29:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FTQvF007040; Wed, 5 Mar 2003 07:29:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FTM7f007030 for ; Wed, 5 Mar 2003 07:29:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25FTUYt003948 for ; Wed, 5 Mar 2003 07:29:30 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05227 for ; Wed, 5 Mar 2003 08:29:24 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:29:16 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:29:03 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:29:03 Z Received: from TheWorld.com ([199.172.62.104] [199.172.62.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:29:02 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id KAA23361; Wed, 5 Mar 2003 10:28:57 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id KAA3531258; Wed, 5 Mar 2003 10:28:52 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Wed, 5 Mar 2003 10:28:52 -0500 From: Quality Quorum To: Pekka Savola cc: Bob Hinden , Margaret Wasserman , Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Mar 2003, Pekka Savola wrote: > On Tue, 4 Mar 2003, Quality Quorum wrote: > > The problem here is software implementation of longest prefix match. > > Up to this point it was limited to a few TLAs with 48 bits which was > > quite doable in software, this draft expands it to 61 > > Note that "this" draft does not do it, it has been already done in > addr-arch-v3, which has been approved by IESG/IAB for publication to > Proposed Standard. Then we had a bunch of RFCs specifying various allocation schemes which effectively paired it down to 48 bit (in some instances 39 bit) longest prefix match. > > > and you are > > proposing 125, which is well beyond capabilities of software based > > lookups. > > "well beyond capabilities of software based lookups" seems to be clearly > false: I've run IPv6 test on Linux / BSD-based systems, which do have > exactly that and have obtained gigabit-grade results, the same as > with IPv4. > > Perhaps that applies in a very specific scenario of sw lookups only. The real life requirement for a low cost router is OC-48 with 40-byte frames, which is about half order of magnitude above hardware limitations of PCI bus. > > Btw, it's 64 and 128, respectively: you seem to be doing exactly what's > forbidden, glueing 2000::/3 in the implementation -- or do you do > 48/64/128-bit lookup for non-2000::/3 routes? It is way easier that that, roughly speaking first you do classification and then you do longest prefix match (if you are in the right TLA or in site local), or hash table lookup (if you are in multicast), or drop. The key word is "software", so it could be easily adapted to non-tectonic changes. Again, the things you are proposing may be a way to go (personally I would love to see every enterprise router to be replaced), however, I suppose that you have to clearly understand consequences of your proposal. It seems to me that, if total router replacement is not the goal, we have to establish at least some transitional period guarantees - say address assignment policies of the next 20 years would guarantee a right of existence for software implementations. > Pekka Savola "You each name yourselves king, yet the Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 5 07:40:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Fej7f007603; Wed, 5 Mar 2003 07:40:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FeiGY007602; Wed, 5 Mar 2003 07:40:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Fef7f007592 for ; Wed, 5 Mar 2003 07:40:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25FenYt006846 for ; Wed, 5 Mar 2003 07:40:49 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17616 for ; Wed, 5 Mar 2003 07:40:44 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:40:26 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:40:25 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:40:25 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:40:24 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h25FeCb07572; Wed, 5 Mar 2003 17:40:12 +0200 Date: Wed, 5 Mar 2003 17:40:11 +0200 (EET) From: Pekka Savola To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: Revised IPv6 charter and DNS discovery In-Reply-To: <200303051522.h25FMxr06256@cichlid.adsl.duke.edu> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Mar 2003, Thomas Narten wrote: > Bob & Margaret have sent me a revised IPv6 charter that I have > forwarded to the IESG/IAB for consideration. It is largely consistent > with the charter that the WG has already seen and supported with one > exception. "DNS discovery" is not included in the charter. FWIW, I support this approach. A BOF would likely be the best approach if we want to explore and find the best solution(s). If we want to push just one/two solutions, dnsop/dnsext (where appropriate) or even v6ops (this is a deployment problem, you could argue ;-) -- but there's already a bit much on that plate) would do. Btw, personally, I have a gut feeling that a neighbor discovery option would probably be a simple approach, though it isn't without its own problems (like monitoring the lifetime of the DNS resolver in the advertisements). > I asked that this item be removed from the charter for several > reasons: > > - If I were to take it to the IESG/IAB (who get to review all WG > charters), I would expect to get strong pushback on including the > DNS discovery work in the IPv6 WG. Reasons would include: > > - this is not IPv6-specific work, it should be done in a broader > IETF context, e.g., where the DNS operational expertise resides > such as in DNSOP. > > - why not just use DHC? I know that many are opposed to including > DHC as part of the solution, but that view is not universally > shared, understood, or agreed too. Especially outside of the IPv6 > community. > > - what about the technical concerns that have been raised regarding > the approach in the current draft? (See Erik Nordmark's > presentation at the Yokohama meeting, for example.) IMO, there has > been a lack of rigorous consideration of the issues that have been > raised. > > Although I have heard the arguments coming from proponents of the > DNS discovery work, I have not been strongly convinced. Moreover, I > also have heard the arguments against the approach in the current > document from others, and find their arguments to have merit as > well. That puts me in the awkward position of arguing for a position > within the IESG that the WG supports, but that I have concerns with > and where I don't have strong answers for addressing those > concerns. The issues here are not black-and-white. I see that there > are multiple sides to the argument, but this group seems to have > difficulty in having a technical discussion about those issues. It > seems like the WG is to a large extent tired of this issue and just > wants to have an RFC. > > - the dns discovery effort has dragged on for way too long (more than > 2 years), and due in part part to the history, I have doubts about > this WG being able to have a productive discussion on the topic > anymore. Being very aware of ongoing discussions and concerns being > discussed on, e.g., the problem-statement list, it is time to make > some decisions and move on. One of those decision may just be that > the idea of a quick-and-simple DNS discovery has missed its window > of opportunity, and we just need to move on. > > - the current approach of interest assumes the use of SL > addresses. Given the issues swirling around SL and to what degree > the WG wants to encourage or limit their usage, I find it hard to > believe that the current ID is a good way to go forward. It would > seem odd to recommend this approach while simultaneously still > having discussions about how much to discourage the usage of > site-local addressing. > > - it is not clear to me there is really consensus for the current > document at this point in time, whatever past concensus there might > have been. Moreover, it's not clear how much support the selected > approach has outside of the IPv6 community. This gets back to an > earlier point about doing the work in consultation with the right > experts. > > Where to go from here? If there is truly interest in continuing this > work, it might make sense to engage the DNSOP WG to see what kind of > interest there is there _for the problem statement_ before even > discussing any particular approach. It might also make sense to host a > BOF on either the narrow topic of DNS discovery or the broader topic > of service discovery. Steve Deering posted a long note a while back on > "serverless discovery" that I think was quite interesting, but much > work needs to be done to flesh that out, assuming there is interest in > doing so. Finally, there is always DHC (the IESG approved DHCPv6 as a > PS at the end of 2002), so the IETF _does_ have a recommended approach > -- it's just one that some people don't like. > > 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 > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 5 07:50:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Foo7f007854; Wed, 5 Mar 2003 07:50:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FooE1007853; Wed, 5 Mar 2003 07:50:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Fol7f007846 for ; Wed, 5 Mar 2003 07:50:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25FotYt009518 for ; Wed, 5 Mar 2003 07:50:55 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06097 for ; Wed, 5 Mar 2003 08:50:48 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:50:46 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:48:45 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:50:46 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:50:43 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h25FoEEI081522; Wed, 5 Mar 2003 16:50:18 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h25Fnvq2020902; Wed, 5 Mar 2003 16:49:58 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53672 from ; Wed, 5 Mar 2003 16:49:52 +0100 Message-Id: <3E65D065.9CAE6B61@hursley.ibm.com> Date: Wed, 05 Mar 2003 11:24:37 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Pekka Savola wrote: > > On Tue, 4 Mar 2003, Bob Hinden & Margaret Wasserman wrote: > > This is a one week IPv6 working group last call for comments on advancing > > the following document as a Proposed Standard: > > > > Title : IPv6 Flow Label Specification > > Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering > > Filename : draft-ietf-ipv6-flow-label-05.txt > > Pages : 8 > > Date : 2003-3-3 > > > > The chairs belive this draft represents the consensus of the working group > > and resolves issues raised during and subsequent to the working group last > > call. However given the time that has elapsed we think a short working > > group last call is desirable to verify the consensus before forwarding the > > document to the IESG. > > [note: I had already written this message once but accidentally cancelled > the message -- hope I don't forget anything] > > In summary, I don't believe the doc is ready to be sent to the IESG. > There are a few major issues to be worked out yet, the last of the the > most important. > > Comments below. > > substantial: > ------------ > > The 3-tuple of the Flow Label and the Source and Destination Address > fields enables efficient IPv6 flow classification, where only IPv6 > main header fields in fixed positions are used. > > ==> this might require some extra analysis somewhere (not in that > particular place, I think). In particular, this seems to say that once > this is published people can happily move to using the three-tuple > classification. The reality is probably quite different, and one must > also consider the big portion of nodes which do not mark the flows. The goal of this document is not to describe use cases. It is to set the minimum conditions hosts and routers must meet. I do not believe we should add use cases to this document. > > A possible fix would be to tone down "enable" (e.g. "make xxx possible") > and add some minor tweaking. I don't think we need to tweak. "Enable" is exactly right. > > To enable applications and transport protocols to define what packets > constitute a flow, the source node MUST provide means for the > applications and transport protocols to specify the Flow Label values > to be used with their flows. > > ==> this requirement seems unacceptable at the moment. This clearly > requires (at least) de-facto API so applications could set Flow Label > values -- and as such does not exist. If it did (and I believe there's > work in progress), there would *have to be* a normative reference to it). > So, clearly a MUST seems to a big no-no. But this is a statement about what hosts must do to make the flow label useful. If you want to standardize a socket API extension that's fine, the Open Group exists for that. However, I believe a MUST is needed. > > A source node MUST ensure that it does not reuse Flow Label values it > is currently using or has recently used when creating new flows. Flow > Label values previously used with a specific pair of source and > destination addresses MUST NOT be assigned to new flows with the same > address pair within 120 seconds of the termination of the previous > flow. > > ==> so, if I make create a raw socket, manually fiddle in the flow label > value which was previously used, and send the packet, the operating system > kernel should hijack it and prevent it from going out? Get real. Perhaps > s/reuse/unintentionally reuse/, or some other rewording? Yes, the stack is supposed to do that. It's not hard. In an earlier version we included an algorithm, but the WG wanted it removed, so we removed it. > > To enable co-existence of different methods in IPv6 nodes, the > methods MUST meet the following basic requirements: > > ==> this and the following points seem a little oddly placed in this memo: > they seem out-of-place, as the rest of the memo seems to concentrate on > entirely different issues. Personally I view specifying how source nodes > should label flows one thing, and the rest entirely another. But I can > live with these, even though I think they're more fit to a non-standards > track document. Then you don't want a change here? > > 5.1 Theft and Denial of Service > > ==> this section mainly deals with issues relating to forging all of the > source,destination,label three-tuple (exception is the last paragraph, > which deals with a trusted-node-but-untrusted-user/application case), > which protects mainly against a DoS attack (resource depletion). > > This seems to overlook the most important part: the typical model today is > that operators perform differentiation of flows *themselves*: this > document proposes to shift that, *over an administrative boundary*, to the > source nodes, which suddenly become trusted to do the right thing. No, it adds the *labelling* of flows to the source, as a new capability. It says *nothing* about how differentiation is done. That is indeed a separate and quite complex discussion, that will keep the QOS community busy for years. The idea is to keep that discussion out of the IPv6 WG, by defining the boundary conditions here, so that the flow label becomes a viable tool for differentiation downstream. I think this was clear in the previous WG discussions. > > This would be equivalent to replacing network ingress filtering (to drop > packets with forged source addresses) to a requirement for nodes to allow > out only packets which include their own source address. No. The checks can perfectly well be applied at ISP ingress. I did want to include more aggressive text about ingress filtering, but in fact it would be out of place. (By the way, do you think nodes *should* be allowed to forge the source address?) > > Needless to say this seems to indicate a major oversight of the > security/operational reality. I'd be very surprised if this was not > pushed back in the IESG unless this caveat is very explicitly documented. I think your interpretation is quite wrong, but we can certainly ask a security expert or two. Thanks for the review, and for the editos below. Brian > > semi-editorial > -------------- > > Nodes keeping dynamic flow state MUST NOT assume packets arriving 120 > seconds or more after the previous packet of a flow still belong to > the same flow, unless a flow state establishment method in use > defines a longer flow state lifetime or the flow state has been > explicitly refreshed within the lifetime duration. > > ==> this is a way too sentence, 5 lines, and constructed in with a > negative: "MUST NOT blahblah, unless foofoo". You really have to read > that a couple of times to understand what it's trying to say. I'd > strongly urge to reword and simplify. > > editorial > --------- > > If an IPv6 node is not providing flow-specific treatment, it MUST > ignore the field when receiving or forwarding a packet. > > ==> reword: "providing .. treatment" seems to sound awkward in the case of > "receiving a packet" (ie. in the case of end-node, not router). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 5 07:51:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Fpd7f007884; Wed, 5 Mar 2003 07:51:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FpdOq007883; Wed, 5 Mar 2003 07:51:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Fpa7f007876 for ; Wed, 5 Mar 2003 07:51:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25Fpivx026113 for ; Wed, 5 Mar 2003 07:51:44 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25247 for ; Wed, 5 Mar 2003 07:51:38 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:51:37 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:51:01 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:51:01 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:51:00 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h25Fo6Xu041076; Wed, 5 Mar 2003 16:50:17 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h25Fneq2011394; Wed, 5 Mar 2003 16:49:40 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21458 from ; Wed, 5 Mar 2003 16:49:29 +0100 Message-Id: <3E65CBF5.AC8F4EFA@hursley.ibm.com> Date: Wed, 05 Mar 2003 11:05:41 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Pekka Savola , Bob Hinden , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt References: <963621801C6D3E4A9CF454A1972AE8F54C6D@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > > > Pekka Savola wrote: > > So, I believe everything starting from: > > [ARCH] also requires that all unicast addresses, except those > > that start with binary value 000, have Interface IDs that are > > 64 bits long and to be constructed in Modified EUI-64 format. > > The format of global unicast address in this case is: [...] > > should be removed, if not the whole section. > > I think it should be kept. There is a logical progression in section > 3.0, from n|m|128-n-m to n|64-n|64 to 3|45|16|64. Only the last one is > an example, but the progression from the generic v6 format seems very > logical to me and examples are generally good. It should certainly be kept. The document is misleading without it, unless the reader has been reading this list all his/her life. Brian -------------------------------------------------------------------- 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 Mar 5 07:52:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Fqa7f007937; Wed, 5 Mar 2003 07:52:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FqaVt007936; Wed, 5 Mar 2003 07:52:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FqV7f007926 for ; Wed, 5 Mar 2003 07:52:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25Fqdvx026406 for ; Wed, 5 Mar 2003 07:52:39 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14465 for ; Wed, 5 Mar 2003 08:52:31 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:52:29 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:50:28 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:52:29 Z Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:52:28 Z Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-green.research.att.com (Postfix) with ESMTP id DD3FC1E106 for ; Wed, 5 Mar 2003 10:52:26 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h25FqQk21610 for ; Wed, 5 Mar 2003 10:52:26 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id A24787B4D for ; Wed, 5 Mar 2003 10:52:25 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Steve Bellovin To: ipng@sunroof.eng.sun.com Subject: local access control prefix draft: draft-bellovin-ipv6-accessprefix-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 10:52:25 -0500 Message-Id: <20030305155225.A24787B4D@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I may have missed the official announcement. But there's a new version of my draft on a local access control prefix in the respositories: draft-bellovin-ipv6-accessprefix-01.txt. Abstract Some very low-end devices are expected to rely on address-based authentication, even though that is not a high-security mechanism. In particular, they may wish to permit access by "local" peers only, for some value of "local". This memo proposes a new Router Advertisement option to supply a list of privileged prefixes. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) -------------------------------------------------------------------- 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 Mar 5 07:53:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FrV7f007984; Wed, 5 Mar 2003 07:53:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25FrUwK007983; Wed, 5 Mar 2003 07:53:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25FrQ7f007973 for ; Wed, 5 Mar 2003 07:53:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25FrYvx026696 for ; Wed, 5 Mar 2003 07:53:35 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14901 for ; Wed, 5 Mar 2003 08:53:25 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:53:23 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:51:21 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:53:21 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 15:53:18 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h25FqgEI086960; Wed, 5 Mar 2003 16:52:46 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h25Fnnq2164604; Wed, 5 Mar 2003 16:49:51 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25372 from ; Wed, 5 Mar 2003 16:49:42 +0100 Message-Id: <3E65CCD9.2EC5E3B5@hursley.ibm.com> Date: Wed, 05 Mar 2003 11:09:29 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Quality Quorum Cc: Pekka Savola , Bob Hinden , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Quality Quorum wrote: > > > One substantial point I'd like to see more discussion on is whether folks > > feel that "Address Format" section, mainly restating what addr-arch-v3-11 > > says on 64 bit IID's, seems like the right thing to do in this document? > > > > I think this point was brought up by at least Thomas Narten and others, > > but I don't remember whether a closure was reached. > > > > So, I believe everything starting from: > > > > [ARCH] also requires that all unicast addresses, except those that > > start with binary value 000, have Interface IDs that are 64 bits long > > and to be constructed in Modified EUI-64 format. The format of > > global unicast address in this case is: > > [...] > > > > should be removed, if not the whole section. > > > > I can live with this but IMO putting 64-bit-interface-ID thing which is > > rather controversial still in too many documents seems like something to > > be careful about. > > The problem here is software implementation of longest prefix match. > Up to this point it was limited to a few TLAs with 48 bits which was > quite doable in software, this draft expands it to 61 and you are > proposing 125, which is well beyond capabilities of software based > lookups. > > I do not see anything specifically wrong with this approach if a complete > enterprise router replacement is a stated goal of IPv6. If not then we > have to address the issue of software based implementations somehow. > > Again, it may be a way to go, but frankly I am in a little shock - > after many years of planing for various hierarchical partitions to find > myself back in CIDR without borders environment and all of it in a matter > of days. I find this surprising. The decision to scrap TLA/NLA was taken a long time ago, and in any case it's always been clear that such boundaries were not architectural, but merely conventions in the address assignment scheme. So any implementation that takes any notice of TLA/NLA was broken anyway. The only boundary that should affect code is the /64 boundary, which is why the paragraph that Pekka cited is valuable. Brian -------------------------------------------------------------------- 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 Mar 5 08:10:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25GAP7f009443; Wed, 5 Mar 2003 08:10:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25GAO7t009442; Wed, 5 Mar 2003 08:10:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25GAL7f009435 for ; Wed, 5 Mar 2003 08:10:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25GATvx002186 for ; Wed, 5 Mar 2003 08:10:29 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09989 for ; Wed, 5 Mar 2003 09:10:23 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 16:10:21 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 16:10:21 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 16:10:21 Z Received: from TheWorld.com ([199.172.62.104] [199.172.62.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 16:10:19 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA12138; Wed, 5 Mar 2003 11:10:18 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA3548289; Wed, 5 Mar 2003 11:10:17 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Wed, 5 Mar 2003 11:10:17 -0500 From: Quality Quorum To: Brian E Carpenter cc: Pekka Savola , Bob Hinden , Margaret Wasserman , Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: <3E65CCD9.2EC5E3B5@hursley.ibm.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I find this surprising. The decision to scrap TLA/NLA was taken > a long time ago, and in any case it's always been clear that > such boundaries were not architectural, but merely conventions > in the address assignment scheme. I would say existence of thses conventions (I am talking about TLA) made incoming transition to v6 a way more feasible. > So any implementation that takes any notice of TLA/NLA was broken > anyway. The only boundary that > should affect code is the /64 boundary, which is why the paragraph > that Pekka cited is valuable. I suppose 125-bit LPM will significantly slow down acceptance of ipv6. I suppose that v6 will benefit from administrative steps setting limits on LPM, at least for transitional period. > > Brian > > Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 5 09:02:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25H2K7f010056; Wed, 5 Mar 2003 09:02:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25H2KUB010055; Wed, 5 Mar 2003 09:02:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25H2H7f010048 for ; Wed, 5 Mar 2003 09:02:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25H2PYt001095 for ; Wed, 5 Mar 2003 09:02:25 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25666 for ; Wed, 5 Mar 2003 10:02:18 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:02:16 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:02:06 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:02:06 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:02:02 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h25H1hLD104662; Wed, 5 Mar 2003 18:01:44 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h25H1ewv098784; Wed, 5 Mar 2003 18:01:40 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44996 from ; Wed, 5 Mar 2003 18:01:33 +0100 Message-Id: <3E662D32.4D4A760C@hursley.ibm.com> Date: Wed, 05 Mar 2003 18:00:34 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Quality Quorum Cc: Pekka Savola , Bob Hinden , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quality Quorum wrote: > > > I find this surprising. The decision to scrap TLA/NLA was taken > > a long time ago, and in any case it's always been clear that > > such boundaries were not architectural, but merely conventions > > in the address assignment scheme. > > I would say existence of thses conventions (I am talking about TLA) made > incoming transition to v6 a way more feasible. > > > So any implementation that takes any notice of TLA/NLA was broken > > anyway. The only boundary that > > should affect code is the /64 boundary, which is why the paragraph > > that Pekka cited is valuable. > > I suppose 125-bit LPM will significantly slow down acceptance of ipv6. > > I suppose that v6 will benefit from administrative steps setting > limits on LPM, at least for transitional period. I'd agree, that is why the /64 boundary is so important. Brian -------------------------------------------------------------------- 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 Mar 5 09:04:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25H477f010099; Wed, 5 Mar 2003 09:04:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25H47cr010098; Wed, 5 Mar 2003 09:04:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25H437f010091 for ; Wed, 5 Mar 2003 09:04:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25H4BYt001732 for ; Wed, 5 Mar 2003 09:04:11 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07512 for ; Wed, 5 Mar 2003 09:04:05 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:04:03 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:02:02 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:04:03 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:04:01 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h25H3OXu088342; Wed, 5 Mar 2003 18:03:25 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h25H3Lq2094478; Wed, 5 Mar 2003 18:03:21 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45020 from ; Wed, 5 Mar 2003 18:03:15 +0100 Message-Id: <3E662D97.14D2C09B@hursley.ibm.com> Date: Wed, 05 Mar 2003 18:02:15 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: Michel Py , Bob Hinden , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Tue, 4 Mar 2003, Michel Py wrote: > > > Pekka Savola wrote: > > > So, I believe everything starting from: > > > [ARCH] also requires that all unicast addresses, except those > > > that start with binary value 000, have Interface IDs that are > > > 64 bits long and to be constructed in Modified EUI-64 format. > > > The format of global unicast address in this case is: [...] > > > should be removed, if not the whole section. > > > > I think it should be kept. There is a logical progression in section > > 3.0, from n|m|128-n-m to n|64-n|64 to 3|45|16|64. Only the last one is > > an example, but the progression from the generic v6 format seems very > > logical to me and examples are generally good. > > A reference to the IESG/IAB recommendation -- or the RIPE policy document > -- is clear enough, IMO. > > And this avoids the follow-up issue that it isn't IMO the good thing to > have _IETF_ document decisions made by _RIR_'s. This hasn't happened. We are trying to publish something that stops at the point where IANA delegation starts. Brian -------------------------------------------------------------------- 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 Mar 5 09:06:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25H6D7f010295; Wed, 5 Mar 2003 09:06:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25H6C5l010291; Wed, 5 Mar 2003 09:06:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25H687f010277 for ; Wed, 5 Mar 2003 09:06:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25H6Gvx019458 for ; Wed, 5 Mar 2003 09:06:16 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29131 for ; Wed, 5 Mar 2003 10:06:10 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:05:40 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:03:38 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:05:38 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:05:37 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id h25H5SXu105976; Wed, 5 Mar 2003 18:05:28 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h25H5Rq2265612; Wed, 5 Mar 2003 18:05:28 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61682 from ; Wed, 5 Mar 2003 18:05:25 +0100 Message-Id: <3E662E1A.647C3216@hursley.ibm.com> Date: Wed, 05 Mar 2003 18:04:26 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" References: <963621801C6D3E4A9CF454A1972AE8F54C6E@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, Michel Py wrote: > > Bob / Margaret / Brian, > > > Bob Hinden & Margaret Wasserman wrote: > > This is a one week IPv6 working group last call for comments > > on advancing the following document as a Proposed Standard: > > Title: IPv6 Flow Label Specification > > Author(s): J. Rajahalme, A. Conta, B. Carpenter, S. Deering > > The parts that I cared about have been preserved; it's a go for me. > > > > The chairs belive this draft represents the consensus of the > > working group and resolves issues raised during and subsequent > > to the working group last call. However given the time that > > has elapsed we think a short working group last call is > > desirable to verify the consensus before forwarding the > > document to the IESG. > > Note: I have not been following this closely, so this might have been > addressed already. If my memory is correct during one of the Atlanta > meetings one of the authors (Brian Carpenter) had some concerns about > the then-current text. Forgive me if I have missed it, I would like to > hear from Brian if the concerns he had at the time have been addressed. > The reason I am specifically interested in Brian's comments is because > about the same time we were discussing the interactions between MHAP and > flow control. My concerns were handled in the various rounds between the authors (mainly by taking stuff out, which is what the WG asked for anyway). Brian -------------------------------------------------------------------- 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 Mar 5 09:12:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HCY7f011158; Wed, 5 Mar 2003 09:12:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25HCXQe011157; Wed, 5 Mar 2003 09:12:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HCQ7f011114 for ; Wed, 5 Mar 2003 09:12:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25HCYYt004840 for ; Wed, 5 Mar 2003 09:12:35 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26973 for ; Wed, 5 Mar 2003 10:12:28 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:12:26 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:12:26 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:12:26 Z Received: from fridge.docomolabs-usa.com ([216.98.102.225] [216.98.102.225]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:12:25 Z Message-Id: <012601c2e33a$2d70ca10$156015ac@T23KEMPF> From: "James Kempf" To: , "Thomas Narten" References: <200303051522.h25FMxr06256@cichlid.adsl.duke.edu> Subject: Re: Revised IPv6 charter and DNS discovery Date: Wed, 5 Mar 2003 09:09:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I support this change. Regarding what to do with the DNS server discovery work, I think a BOF would be an appropriate approach. Steve Deering's serverless discovery is an interesting approach, and I think it deserves some consideration, but I've heard plausible reasons why DNS server discovery might be an exception to the general case of service discovery so one topic of such a BOF would be sorting that out. jak ----- Original Message ----- From: "Thomas Narten" To: Sent: Wednesday, March 05, 2003 7:22 AM Subject: Revised IPv6 charter and DNS discovery > note: AD hat on. > > Bob & Margaret have sent me a revised IPv6 charter that I have > forwarded to the IESG/IAB for consideration. It is largely consistent > with the charter that the WG has already seen and supported with one > exception. "DNS discovery" is not included in the charter. > > I asked that this item be removed from the charter for several > reasons: > > - If I were to take it to the IESG/IAB (who get to review all WG > charters), I would expect to get strong pushback on including the > DNS discovery work in the IPv6 WG. Reasons would include: > > - this is not IPv6-specific work, it should be done in a broader > IETF context, e.g., where the DNS operational expertise resides > such as in DNSOP. > > - why not just use DHC? I know that many are opposed to including > DHC as part of the solution, but that view is not universally > shared, understood, or agreed too. Especially outside of the IPv6 > community. > > - what about the technical concerns that have been raised regarding > the approach in the current draft? (See Erik Nordmark's > presentation at the Yokohama meeting, for example.) IMO, there has > been a lack of rigorous consideration of the issues that have been > raised. > > Although I have heard the arguments coming from proponents of the > DNS discovery work, I have not been strongly convinced. Moreover, I > also have heard the arguments against the approach in the current > document from others, and find their arguments to have merit as > well. That puts me in the awkward position of arguing for a position > within the IESG that the WG supports, but that I have concerns with > and where I don't have strong answers for addressing those > concerns. The issues here are not black-and-white. I see that there > are multiple sides to the argument, but this group seems to have > difficulty in having a technical discussion about those issues. It > seems like the WG is to a large extent tired of this issue and just > wants to have an RFC. > > - the dns discovery effort has dragged on for way too long (more than > 2 years), and due in part part to the history, I have doubts about > this WG being able to have a productive discussion on the topic > anymore. Being very aware of ongoing discussions and concerns being > discussed on, e.g., the problem-statement list, it is time to make > some decisions and move on. One of those decision may just be that > the idea of a quick-and-simple DNS discovery has missed its window > of opportunity, and we just need to move on. > > - the current approach of interest assumes the use of SL > addresses. Given the issues swirling around SL and to what degree > the WG wants to encourage or limit their usage, I find it hard to > believe that the current ID is a good way to go forward. It would > seem odd to recommend this approach while simultaneously still > having discussions about how much to discourage the usage of > site-local addressing. > > - it is not clear to me there is really consensus for the current > document at this point in time, whatever past concensus there might > have been. Moreover, it's not clear how much support the selected > approach has outside of the IPv6 community. This gets back to an > earlier point about doing the work in consultation with the right > experts. > > Where to go from here? If there is truly interest in continuing this > work, it might make sense to engage the DNSOP WG to see what kind of > interest there is there _for the problem statement_ before even > discussing any particular approach. It might also make sense to host a > BOF on either the narrow topic of DNS discovery or the broader topic > of service discovery. Steve Deering posted a long note a while back on > "serverless discovery" that I think was quite interesting, but much > work needs to be done to flesh that out, assuming there is interest in > doing so. Finally, there is always DHC (the IESG approved DHCPv6 as a > PS at the end of 2002), so the IETF _does_ have a recommended approach > -- it's just one that some people don't like. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 5 09:16:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HGC7f011504; Wed, 5 Mar 2003 09:16:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25HGC7p011503; Wed, 5 Mar 2003 09:16:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HG97f011496 for ; Wed, 5 Mar 2003 09:16:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25HGHvx023612 for ; Wed, 5 Mar 2003 09:16:17 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29022 for ; Wed, 5 Mar 2003 10:16:09 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:15:19 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:14:43 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:14:43 Z Received: from TheWorld.com ([199.172.62.106] [199.172.62.106]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:14:43 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id MAA09600; Wed, 5 Mar 2003 12:14:31 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id MAA3532470; Wed, 5 Mar 2003 12:14:27 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Wed, 5 Mar 2003 12:14:26 -0500 From: Quality Quorum To: Brian E Carpenter cc: Pekka Savola , Bob Hinden , Margaret Wasserman , Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: <3E662D32.4D4A760C@hursley.ibm.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > I suppose 125-bit LPM will significantly slow down acceptance of ipv6. > > > > I suppose that v6 will benefit from administrative steps setting > > limits on LPM, at least for transitional period. > > I'd agree, that is why the /64 boundary is so important. Glad to hear it. I would say that 61-bit LPM while doable is pretty steep for software still. Can we have say allocation policy for transition limiting it to lower number ? > > Brian > Thanks, Aelksey -------------------------------------------------------------------- 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 Mar 5 09:19:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HJK7f011710; Wed, 5 Mar 2003 09:19:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25HJKFQ011709; Wed, 5 Mar 2003 09:19:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HJG7f011699 for ; Wed, 5 Mar 2003 09:19:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25HJPvx024671 for ; Wed, 5 Mar 2003 09:19:25 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00583 for ; Wed, 5 Mar 2003 09:19:17 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:18:26 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:16:07 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:18:08 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:18:07 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h25HHsc08751; Wed, 5 Mar 2003 19:17:54 +0200 Date: Wed, 5 Mar 2003 19:17:54 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Michel Py , Bob Hinden , Margaret Wasserman , Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: <3E662D97.14D2C09B@hursley.ibm.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > On Tue, 4 Mar 2003, Michel Py wrote: > > > > Pekka Savola wrote: > > > > So, I believe everything starting from: > > > > [ARCH] also requires that all unicast addresses, except those > > > > that start with binary value 000, have Interface IDs that are > > > > 64 bits long and to be constructed in Modified EUI-64 format. > > > > The format of global unicast address in this case is: [...] > > > > should be removed, if not the whole section. > > > > > > I think it should be kept. There is a logical progression in section > > > 3.0, from n|m|128-n-m to n|64-n|64 to 3|45|16|64. Only the last one is > > > an example, but the progression from the generic v6 format seems very > > > logical to me and examples are generally good. > > > > A reference to the IESG/IAB recommendation -- or the RIPE policy document > > -- is clear enough, IMO. > > > > And this avoids the follow-up issue that it isn't IMO the good thing to > > have _IETF_ document decisions made by _RIR_'s. > > This hasn't happened. We are trying to publish something that stops > at the point where IANA delegation starts. My perception is that the /48 "border" is inside the IANA delegation. (As is /64, but that's a different issue). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 5 09:57:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HvL7f012895; Wed, 5 Mar 2003 09:57:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25HvLe3012894; Wed, 5 Mar 2003 09:57:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25HvH7f012887 for ; Wed, 5 Mar 2003 09:57:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25HvQvx008145 for ; Wed, 5 Mar 2003 09:57:26 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29083 for ; Wed, 5 Mar 2003 09:57:19 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:56:59 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:54:40 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:56:40 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 17:56:40 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h25HuYK09074; Wed, 5 Mar 2003 19:56:35 +0200 Date: Wed, 5 Mar 2003 19:56:34 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Bob Hinden & Margaret Wasserman , Subject: trusting end-nodes to do the right thing [Re: IPv6 w.g. Last Call on "IPv6 Flow Label Specification"] In-Reply-To: <3E65D065.9CAE6B61@hursley.ibm.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We may be treading into a very difficult situation (in some ways similar to why MIPv6 got pushback from the IESG, IMO), and to be pre-emptive, I'd really appreciate if folks would have a look at the particular issue (at the end of the mail) and think whether it is a problem or not. On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > The 3-tuple of the Flow Label and the Source and Destination Address > > fields enables efficient IPv6 flow classification, where only IPv6 > > main header fields in fixed positions are used. > > > > ==> this might require some extra analysis somewhere (not in that > > particular place, I think). In particular, this seems to say that once > > this is published people can happily move to using the three-tuple > > classification. The reality is probably quite different, and one must > > also consider the big portion of nodes which do not mark the flows. > > The goal of this document is not to describe use cases. It is > to set the minimum conditions hosts and routers must meet. I do > not believe we should add use cases to this document. I believe the original text does not give a realistic picture of the situation. For the purpose of minimum conditions, the text could be removed altogether, of course -- that would be fine by me. I could also live with (by a thread :-) the current version, but I really believe it should be changed slightly. > > To enable applications and transport protocols to define what packets > > constitute a flow, the source node MUST provide means for the > > applications and transport protocols to specify the Flow Label values > > to be used with their flows. > > > > ==> this requirement seems unacceptable at the moment. This clearly > > requires (at least) de-facto API so applications could set Flow Label > > values -- and as such does not exist. If it did (and I believe there's > > work in progress), there would *have to be* a normative reference to it). > > So, clearly a MUST seems to a big no-no. > > But this is a statement about what hosts must do to make the flow label > useful. No, that's not correct, or either of us is misunderstanding the paragraph above (if so, a wording change is needed). The nodes (kernel, in particular) are able to mark flows by itself, without any interaction from the applications -- so having apps have a MUST possibility to influence the flow labeling is undoubtedly useful, but certainly not something requiring MUST, considering the current situation. Note: I'd argue for MUST myuself if we had had a standard (or even de-facto standard!) mechanism specified (and hopefully implemented) for 1 year before this being sent to the IESG. > If you want to standardize a socket API extension that's fine, > the Open Group exists for that. However, I believe a MUST is needed. A MUST without a means is bad practise, IMO. > > A source node MUST ensure that it does not reuse Flow Label values it > > is currently using or has recently used when creating new flows. Flow > > Label values previously used with a specific pair of source and > > destination addresses MUST NOT be assigned to new flows with the same > > address pair within 120 seconds of the termination of the previous > > flow. > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > value which was previously used, and send the packet, the operating system > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > s/reuse/unintentionally reuse/, or some other rewording? > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > we included an algorithm, but the WG wanted it removed, so we removed it. Yes, the stack can do it easily -- no doubt about that -- but it's *wrong*; this is connected to the security issue, below. > > To enable co-existence of different methods in IPv6 nodes, the > > methods MUST meet the following basic requirements: > > > > ==> this and the following points seem a little oddly placed in this memo: > > they seem out-of-place, as the rest of the memo seems to concentrate on > > entirely different issues. Personally I view specifying how source nodes > > should label flows one thing, and the rest entirely another. But I can > > live with these, even though I think they're more fit to a non-standards > > track document. > > Then you don't want a change here? I can live without it -- waiting to hear others' opinions -- but I think the source node behaviour is entirely different issue from the network treatment. > > 5.1 Theft and Denial of Service > > > > ==> this section mainly deals with issues relating to forging all of the > > source,destination,label three-tuple (exception is the last paragraph, > > which deals with a trusted-node-but-untrusted-user/application case), > > which protects mainly against a DoS attack (resource depletion). > > > > This seems to overlook the most important part: the typical model today is > > that operators perform differentiation of flows *themselves*: this > > document proposes to shift that, *over an administrative boundary*, to the > > source nodes, which suddenly become trusted to do the right thing. > > No, it adds the *labelling* of flows to the source, as a new capability. The labeling with current "service model" leads to differentiation. I'll try to reword it again below. If the "service model" would be such that the source node is *not* expected to label flows correctly, I'd certainly agree. > It says *nothing* about how differentiation is done. That is indeed > a separate and quite complex discussion, that will keep the QOS > community busy for years. I believe a bit similar arguments were on the table when mobileip working group proposed MIPv6 to the IESG, and it got pushed down, as "doesn't work, be more specific". That was some 2-3 years ago, and only now MIPv6 is nearing completion. I'd rather handle these kind of issues before IESG, if possible. The problems are different, but there seem to be some dangerous common elements. > The idea is to keep that discussion out > of the IPv6 WG, by defining the boundary conditions here, so that > the flow label becomes a viable tool for differentiation downstream. My fear is that false assumptions lead to wrong conclusions and broken tools, and wasted effort (both from IPv6 wg and especially from the follow-up wgs). > I think this was clear in the previous WG discussions. Unfortunately, the flood was so huge at a point that I couldn't keep up (because I didn't really even care, except whether WG would go on a course which seems really problematic, like now) > > This would be equivalent to replacing network ingress filtering (to drop > > packets with forged source addresses) to a requirement for nodes to allow > > out only packets which include their own source address. > > > (By the way, do > you think nodes *should* be allowed to forge the source address?) I'll answer this first. The nodes certainly should be allowed (in the kernel level) to forge the source addresses: any model which forces this is broken. The reason for breakage is that such a model assumes that the nodes behave "properly". For most cases, that is correct. But because there is still a huge number of systems behaving differently, you cannot depend on it, and assuming it is being done would be wrong. The right (my humble POV, of course :-) answers to your question are: - no, the user privileged process on a node should not be able to set the source address (no problem today) - no, the *network* where the node is attached to should not allow the user to forge the source address (note: different administrative entity) > No. The checks can perfectly well be applied at ISP ingress. Yes, but as the first comment seems to show, in practise this checking would be de-facto removed for performance etc. reasons. > I did want to include more aggressive text about ingress > filtering, but in fact it would be out of place. I'm not sure which kind of text you're referring to, but IMO ingress filtering misses the biggest point. > > Needless to say this seems to indicate a major oversight of the > > security/operational reality. I'd be very surprised if this was not > > pushed back in the IESG unless this caveat is very explicitly documented. > > I think your interpretation is quite wrong, but we can certainly ask a > security expert or two. Ok. To try to clarify what I meant, let me try to explain it again. Any model that requires that source nodes prevent the root/administrator from willingly doing something, and more or less *depending on that* is broken. Let me try to give an example. When Windows XP was being published, some very popular magazines were writing about their belief that adding "raw sockets" functionality would be catastrophic for the Internet, degrade security as people could "now" send any kind of packets they'd want etc. The reality was entirely different. Such can be done *anyway*, using other implementations, using different mechanisms to achieve the same goal, etc. This is a similar issue. Given an *untrusted* node, specifying mechanisms which try to make the *untrusted* node do something you'd like to trust (to a rather full extent) seems *completely* bogus.. Certainly, one should specify checks that user-mode applications MUST NOT be able to re-use flow labels within a lifetime, but that's entirely different from the approach in the draft. Certainly, this is a very problematic issue (which was thought to be solved later, in some other w.g.). I'm not requiring it be solved here. But I'm requiring that we don't pass the problem on without stating *very* explicitly the issues why it might/might not work properly -- so that any followup efforts that might start to build QoS mechanisms on this would not start with an entirely different set of assumptions (easily leading to wrong conclusions and broken tools). I'm not sure if I managed to make the point any clearer, I hope so. I'd also really appreciate comment on this viewpoint (for or against :-) from everybody. Especially those with (ISP) operator [the "customer of the IETF" in this instance] or security background would be encouraged to speak up. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 5 10:08:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25I8M7f013115; Wed, 5 Mar 2003 10:08:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25I8MCf013114; Wed, 5 Mar 2003 10:08:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25I8I7f013105 for ; Wed, 5 Mar 2003 10:08:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25I8QYt023952 for ; Wed, 5 Mar 2003 10:08:26 -0800 (PST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24727 for ; Wed, 5 Mar 2003 11:08:21 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBA005N5FO00C@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 05 Mar 2003 11:07:13 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBA00GNJFNYX4@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 05 Mar 2003 11:07:12 -0700 (MST) Date: Wed, 05 Mar 2003 10:08:23 -0800 From: Alain Durand Subject: Re: Revised IPv6 charter and DNS discovery In-reply-to: <200303051522.h25FMxr06256@cichlid.adsl.duke.edu> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Message-id: <749EF37D-4F35-11D7-BF5C-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, [co-Author of the DNS discovery draft hat on] I agree with your assessment that this proposal has missed its window of opportunity. We could probably do a very interesting post-mortem analysis why in the context of the problem-statement list, but this is not the topic for today's discussion. Now that DHCPv6 is eventually going to be published and implemented, the pressure for an alternate solution specifically for DNS is much lower and I would agree we should now step back and look at the more general problem from a fresh start. There are actually two different topics that could be discussed in a bof: - is DHCP enough for general parameter configuration or is there a significant enough problem space where its not applicable/desirable? For example, for address configuration, we have DHCP and stateless autoconf. Does this dichotomy between server-helped and self-derived configuration applies to other services? - What does it mean to use 'well known voluntary ambiguous' addresses for service configuration? This is a discussion I had with Steve Deering before he went on sabbatical. This is the equivalent of the '911' service: wherever you are, you dial 911 and you are connected to the emergency service. Can we use this paradigm for services that are supposed to be somehow 'universal'? For example, you want a NTP server, try '777::1', you want a DNS server, try '411::1',... Charge to the network to make sure the 'call' connects to the right place. The devil is, of course, in this last sentence. - Alain. -------------------------------------------------------------------- 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 Mar 5 10:17:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25IHg7f013269; Wed, 5 Mar 2003 10:17:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25IHgo5013268; Wed, 5 Mar 2003 10:17:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25IHc7f013261 for ; Wed, 5 Mar 2003 10:17:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25IHlYt027356 for ; Wed, 5 Mar 2003 10:17:47 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03806 for ; Wed, 5 Mar 2003 10:17:41 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 18:17:40 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Wed, 5 Mar 2003 18:17:40 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Wed, 5 Mar 2003 18:17:40 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay1.sun.com with ESMTP; Wed, 5 Mar 2003 18:17:39 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h25IHcY20379; Wed, 5 Mar 2003 10:17:38 -0800 (PST) From: Bill Manning Message-Id: <200303051817.h25IHcY20379@boreas.isi.edu> Subject: Re: Revised IPv6 charter and DNS discovery In-Reply-To: <749EF37D-4F35-11D7-BF5C-00039376A6AA@sun.com> from Alain Durand at "Mar 5, 3 10:08:23 am" To: Alain.Durand@Sun.COM (Alain Durand) Date: Wed, 5 Mar 2003 10:17:37 -0800 (PST) Cc: narten@us.ibm.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As a co-author of a couple of previous DNS discovery IDs, I would have to agree that as postulated, the current DNS discovery work has pretty much been OBE. (overtaken by events) There have been two distinct BOFs on this idea in the last five years so I don't think another BOF will be very productive. % Thomas, % % [co-Author of the DNS discovery draft hat on] % % I agree with your assessment that this proposal % has missed its window of opportunity. % We could probably do a very interesting post-mortem analysis % why in the context of the problem-statement list, but this is not % the topic for today's discussion. % % Now that DHCPv6 is eventually going to be published and implemented, % the pressure for an alternate solution specifically for DNS is much % lower % and I would agree we should now step back and look % at the more general problem from a fresh start. % % There are actually two different topics that could be discussed % in a bof: % % - is DHCP enough for general parameter configuration or is % there a significant enough problem space where its not % applicable/desirable? For example, for address configuration, % we have DHCP and stateless autoconf. Does this dichotomy % between server-helped and self-derived configuration applies to % other services? % % - What does it mean to use 'well known voluntary ambiguous' addresses % for service configuration? % This is a discussion I had with Steve Deering before he went % on sabbatical. This is the equivalent of the '911' service: % wherever you are, you dial 911 and you are connected to the emergency % service. Can we use this paradigm for services that are % supposed to be somehow 'universal'? % For example, you want a NTP server, try '777::1', you want a DNS % server, % try '411::1',... Charge to the network to make sure the 'call' % connects % to the right place. The devil is, of course, in this last sentence. % % % - Alain. % % -------------------------------------------------------------------- % 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 % -------------------------------------------------------------------- % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- 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 Mar 5 10:29:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25ITn7f013515; Wed, 5 Mar 2003 10:29:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25ITmf6013512; Wed, 5 Mar 2003 10:29:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25ITi7f013504 for ; Wed, 5 Mar 2003 10:29:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25ITqYt001713 for ; Wed, 5 Mar 2003 10:29:52 -0800 (PST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13823 for ; Wed, 5 Mar 2003 11:29:46 -0700 (MST) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBA00L2IGNQ0S@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 05 Mar 2003 11:28:38 -0700 (MST) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBA00G5YGNNX4@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 05 Mar 2003 11:28:38 -0700 (MST) Date: Wed, 05 Mar 2003 10:29:48 -0800 From: Alain Durand Subject: Re: Revised IPv6 charter and DNS discovery In-reply-to: <200303051817.h25IHcY20379@boreas.isi.edu> To: Bill Manning Cc: narten@us.ibm.com, ipng@sunroof.eng.sun.com Message-id: <726E7835-4F38-11D7-BF5C-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, March 5, 2003, at 10:17 AM, Bill Manning wrote: > > As a co-author of a couple of previous DNS discovery IDs, I would > have to agree that as postulated, the current DNS discovery work > has pretty much been OBE. (overtaken by events) > There have been two distinct BOFs on this idea in the last five years > so I don't think another BOF will be very productive. Bill, Note that I'm not suggesting a bof on DNS discovery mechanism per se, but a bof on generic service discovery using well known, voluntarily ambiguous addresses. - Alain. -------------------------------------------------------------------- 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 Mar 5 12:04:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25K4O7f014952; Wed, 5 Mar 2003 12:04:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25K4OhD014951; Wed, 5 Mar 2003 12:04:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25K4K7f014944 for ; Wed, 5 Mar 2003 12:04:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25K4Tvx024899 for ; Wed, 5 Mar 2003 12:04:29 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12189 for ; Wed, 5 Mar 2003 13:04:23 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 20:04:01 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Wed, 5 Mar 2003 20:03:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Wed, 5 Mar 2003 20:03:59 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP; Wed, 5 Mar 2003 20:03:59 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.55]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA06746; Wed, 5 Mar 2003 12:03:32 -0800 (PST) Message-Id: <5.1.0.14.2.20030305145945.046366d8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 05 Mar 2003 15:00:38 -0500 To: Thomas Narten , Erik Nordmark From: Margaret Wasserman Subject: Request to Advance "IPv6 Global Unicast Address Format" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : IPv6 Global Unicast Address Format Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipv6-unicast-aggr-v2-02.txt Pages : 5 Date : 2003-3-3 A working group last call for this document was completed on February 21, 2003. The new draft resolves issues raised during the last call. This documented replaces RFC2374, "An IPv6 Aggregatable Global Unicast Address Format". RFC2374 will become historic. Margaret Wasserman IPv6 Working Group co-chair -------------------------------------------------------------------- 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 Mar 5 14:38:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25Mcd7f017225; Wed, 5 Mar 2003 14:38:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h25McduG017224; Wed, 5 Mar 2003 14:38:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h25McZ7f017217 for ; Wed, 5 Mar 2003 14:38:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h25MciYt023260 for ; Wed, 5 Mar 2003 14:38:44 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27494 for ; Wed, 5 Mar 2003 14:38:38 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 22:38:37 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 22:38:37 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 22:38:37 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 5 Mar 2003 22:38:36 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA13787; Wed, 5 Mar 2003 14:38:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h25McYD02050; Wed, 5 Mar 2003 14:38:34 -0800 X-mProtect: <200303052238> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.154, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQfC7F9; Wed, 05 Mar 2003 14:38:31 PST Message-Id: <4.3.2.7.2.20030305143621.02332bc0@mailhost.iprg.nokia.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Mar 2003 14:38:23 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden & Margaret Wasserman Subject: Draft IPv6 working group charter Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_367650823==_" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_367650823==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Attached is a copy of the charter we sent to the Internet ADs. Bob Hinden & Margaret Wasserman --=====================_367650823==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ipv6-wg-charter-10.txt" Internet Protocol Version 6 (IPv6) Working Group Charter -- DRAFT Chairs: Bob Hinden Margaret Wasserman Description of the Working Group: The IPv6 working group is responsible for the specification and standardization of the Internet Protocol version 6 (IPv6). IPv6 provides a much larger global addresses space than its predecessor IPv4. This enables global end-to-end communication and restores valuable properties of the IP architecture that have been lost in the IPv4 Internet. The core IPv6 standards are widely implemented and are in the early stages of global deployment. The IPv6 working group was originally chartered by the IESG as the IP Next Generation (IPng) working group to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. The primary focus of the IPv6 w.g. is to complete the standardization of the IPv6 protocols. The working group's responsibilities are: - Completing work on the IPv6 working group documents as described below, and - Reviewing and updating IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate. The IPv6 working group's standardization responsibilities are divided into two areas: Urgent for Deployment, and Completing Current Work. Priority will be given to the first area. The work items in each priority area are as follows: Urgent For Deployment - Complete Prefix Delegation requirements and publish. Related work is: o Work with DHCPv6 working group to write DHCPv6 option for IPv6 prefix delegation. o Develop Proxy Router Advertisement solution for prefix delegation and publish. This enable a simple site border router to re-advertise downstream a prefix it hears on it's upstream link. Use Multi-Link subnet work as basis for this. Note: general multi-link subnet work will be done elsewhere in the IETF. - Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and publish. Current Work - Complete work on "A Flexible method to manage the assignment of bits of an IPv6 address block". - Revise "Aggregatable Unicast Addresses" (RFC2374) to remove TLA/NLA/SLA terminology. - Revise "Basic Sockets Extensions" (RFC2553) and publish. - Revise "Advanced Sockets API" (RFC2292) and publish. - Complete "Default Router Preferences, More-Specific Routes, and Load Sharing" and publish. - Update to ICMPv6 (RFC2463) and publish. - Complete "Node Information Queries" and publish. - Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) and publish. - Update "Privacy Extensions for Stateless Autoconfiguration" document (RFC3041) and publish. - Complete work on IPv6 Node Requirements and publish. - Complete work on Flow Label and publish. - Explore and document the issues with site-local addressing. Determine appropriate limitations on the use of site-local addresses, and document those limitations. - Complete work on Scoped Addressing Architecture and publish. - Update IPv6 over PPP (RFC2472) and publish (may be done in PPP Extension w.g.). - Review Point-to-point link support in IPv6 and decide if any IPv6 specifications need to be updated. - Complete work on "Link Scoped IPv6 Multicast Addresses" and publish. All new work items not listed above require the approval of the working group and IESG before they will be taken on by the working group. Goals & Milestones Feb 03 Submit "A Flexible method to manage the assignment of bits of an IPv6 address block" to the IESG for Informational. Feb 03 Submit Flow Label specification to IESG for Proposed Standard. Feb 03 Submit Routing Table MIB to IESG for Proposed Standard. Mar 03 Submit Prefix Delegation requirements and submit to IESG for Informational. Mar 03 Draft on Proxy RA solution for prefix delegation. Mar 03 Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology. Apr 03 Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard. Apr 03 Submit TCP MIB to IESG for Proposed Standard. Apr 03 Submit IPv6 Node Requirements to IESG for Informational. May 03 Resubmit Node Information Queries to IESG for Proposed Standard. May 03 Submit UDP MIB to IESG for Proposed Standard. Jun 03 Submit IP MIB to IESG for Proposed Standard. Jun 03 Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard Jun 03 Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard. Jun 03 Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard. Jul 03 Submit Proxy RA to IESG for Proposed Standard. Jul 03 Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard. Aug 03 Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard Aug 03 Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard. Nov 03 Re-charter or close working group. --=====================_367650823==_-- -------------------------------------------------------------------- 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 Mar 5 22:25:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h266Pl7f022791; Wed, 5 Mar 2003 22:25:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h266PkBD022790; Wed, 5 Mar 2003 22:25:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h266Pg7f022783 for ; Wed, 5 Mar 2003 22:25:42 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h266Ppvx024723 for ; Wed, 5 Mar 2003 22:25:51 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08484 for ; Wed, 5 Mar 2003 22:25:45 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 06:25:44 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 06:23:42 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 06:25:44 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 06:25:41 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B710715210; Thu, 6 Mar 2003 15:26:22 +0900 (JST) Date: Thu, 06 Mar 2003 15:25:58 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: PD lifetime issues again (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_Mar__6_15:25:58_2003-1" X-Dispatcher: imput version 20000228(IM140) Lines: 301 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Thu_Mar__6_15:25:58_2003-1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Sorry for not responding sooner. =46rom this message, I'll separate the thread for each particular issue. >>>>> On Fri, 28 Feb 2003 00:46:37 +0000,=20 >>>>> Ole Troan said: >> 1. Issues about the preferred and valid lifetimes were not fully >> addressed. I've not seen consensus on this in the dhc-wg ML. >> Please re-check the thread entitled "PD lifetimes" that started on >> Thu, 23 Jan 2003 19:18:57 +0900. > what specifically are you referring to here? in my opinion we reached > consensus that: > - both preferred and valid lifetimes are needed > - prefixes or addresses derived from the prefix MUST not be used > beyond the valid lifetime These two are okay. > - adding P and V bits to specify if a prefix advertised in an RA > should use a fixed lifetime or a real time lifetime, is not needed > as it does not seem to add value or solve any specific problem. I'm not yet fully convinced on this, particularly about the P bit. The motivation of having the preferred lifetime should be to allow the delegating router to control smooth renumbering. In a renumbering phase, the preferred (and valid) lifetime in RA at a downstream link should be decreasing in real time. But it is not clear to me how the preferred lifetime in RA is decreasing. The PD draft just says: A requesting router MAY use the preferred lifetime specified in the IA_PD Prefix option. (Section 11.1 of prefix-delegation-02) What does "use" mean here? If it means the requesting router copies the PD pltime to the RA pltime, the latter won't decrease. If this has the same meaning as that for the valid lifetime: the requesting router MUST set the valid lifetime in those advertisements to be no later than the valid lifetime specified in the IA_PD Prefix option. (just before the sentence cited above) why not just use the same phrase? I also requested that the default value of the valid lifetime in a PD prefix option be larger than AdvValidLifetime (see the "summary" part of the message). At least I've not seen a "consensus" to reject the request. Erik rather seemed to share my motivation according to the discussion after the attached message below. Furthermore, I still have a concern about the difference between the role of prefix pltime and that of address pltime (I have repeatedly tried to point it out, but perhaps I was not clear enough). The former is a kind of an optional parameter, while the latter is a mandatory one: A requesting router MAY use the preferred lifetime specified in the IA_PD Prefix option. (Section 11.1 of prefix-delegation-02) In a message sent by a server to a client, the client MUST use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes. (Section 22.6. of dhc-dhcpv6-28) Note the former uses a MAY but the latter uses a MUST. Despite the difference on the requirement level, the PD draft has (almost) exactly the same recommendation about the relationship between T1/T2 and pltime as that of the DHCPv6 draft: Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the prefixes in the IA_PD, respectively. (Section 8 of prefix-delegation-02) Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA, respectively. (Section 22.4 of dhc-dhcpv6-28) The recommendation of DHCPv6 seems reasonable, since the client MUST use the preferred lifetime in the IA. In the PD case, however, the requesting router (i.e. the client) MAY "NOT" use the preferred lifetimes in the IA_PD, which makes the recommendation less reasonable. Now I have a concrete proposal. - add a special value for the PD preferred lifetime which means the requesting router can choose the RA preferred lifetime. 0 would be a reasonable value for this. - change the default value of the PD preferred lifetime to the special value. - change the requesting router behavior on the received preferred lifetime to: (if the preferred lifetime in IA_PD is not the special value) the requesting router MUST set the preferred lifetime in those advertisements to be no later than the preferred lifetime specified in the IA_PD Prefix option. - change the recommendation on the T1/T2 values so that they are based on the valid lifetimes, e.g.: Recommended values for T1 and T2 are .5 and .8 times the shortest valid lifetime of the prefixes in the IA_PD, respectively. - (assuming the change on the recommendation) choose the default value of the PD valid lifetime so that the RA valid lifetime won't decrease as long as Renew/Reply exchanges succeed. 5 times the AdvValidLifetime would be a good candidate. - (optional) it may also make the intention clearer if we could change the field name of PD valid and preferred lifetimes to, e.g., "lease-time" and "adv-preferred-lifetime", respectively. With this proposal, the typical (default) operation will be like this: (assuming 0 as the "special value" for the PD preferred lifetime) - the delegating router suggests a following parameters for each prefix: AdvValidLifetime * 5 (150 days) as the valid lifetime 0 as the preferred lifetime and T1/T2 be 75/120 days. - before T2 expires, the requesting router can use any value for RA=20 valid lifetime not larger than 30 days (AdvValidLifetime). In particular, it can use the constant value of AdvValidLifetime. - similarly, the requesting router can use any value for RA preferred lifetime not larger than RA valid lifetime until T2 expires. In particular, it can use the constant value of AdvPreferredLifetime. When the delegating side wants to initiate a renumbering, the delegating router will specify a positive (but finite) value as PD preferred lifetime. Then the succeeding RA preferred lifetime will decrement in real time. I strongly believe the proposed change makes the specification clearer in terms of the intended usage of PD (comparing to that of address assignment). Also, the proposed change does not require a large change on the actual behavior on the current draft; it just changes the default value of the lifetime field, and introduces a minor change about the relationship between PD lifetimes and RA lifetimes. Thus, I don't think the change affects early implementations much. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_Mar__6_15:25:58_2003-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.1.0) for jinmei@localhost (single-drop); Mon, 27 Jan 2003 00:17:14 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0QEAiR88146 for ; Sun, 26 Jan 2003 23:10:44 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id h0QEAiv01832 for ; Sun, 26 Jan 2003 23:10:44 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id XAA01397 for ; Sun, 26 Jan 2003 23:10:44 +0900 (JST) Received: from mx.toshiba.co.jp (mx1.toshiba.co.jp [133.199.160.215]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id h0QEAhn20051 for ; Sun, 26 Jan 2003 23:10:43 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA12899; Sun, 26 Jan 2003 23:10:43 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp with ESMTP id XAA20525 for ; Sun, 26 Jan 2003 23:10:42 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb5.toshiba.co.jp with ESMTP id h0QEAf61019259 for ; Sun, 26 Jan 2003 23:10:41 +0900 (JST) Received: by orange.kame.net (Postfix) id AE26D7151; Sun, 26 Jan 2003 23:10:41 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (sh.wide.ad.jp [203.178.137.85]) by orange.kame.net (Postfix) with ESMTP id 4E1997144 for ; Sun, 26 Jan 2003 23:10:41 +0900 (JST) Received: from www1.ietf.org (ietf.org [132.151.1.19]) by sh.wide.ad.jp (8.11.6+3.4W/8.11.0/smtpfeed 1.18) with ESMTP id h0QEAdi16036; Sun, 26 Jan 2003 23:10:39 +0900 (JST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QEJXJ04833; Sun, 26 Jan 2003 09:19:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q9VHJ25031 for ; Sun, 26 Jan 2003 04:31:17 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15452 for ; Sun, 26 Jan 2003 04:10:51 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q9EHR86987; Sun, 26 Jan 2003 18:14:17 +0900 (JST) Date: Sun, 26 Jan 2003 18:14:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: References: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-UIDL: ~jJ!!*:o"!W2*#!K&o"! X-Spam-Status: No, hits=-9.6 required=5.0 tests=AWL,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT version=2.41 X-Spam-Level: >>>>> On Sat, 25 Jan 2003 06:46:26 +0100 (CET), >>>>> Erik Nordmark said: > Presumably the PD draft could do this as well by having a bit (or two) > indicating wheter the lifetime(s) should decrement in real time or be > constant. > Would that make sense? Yes, *if we want to allow the delegating router to have the ability to control the downstream valid and preferred lifetimes*. Actually, RFC 2894 (Router Renumbering for IPv6) has a similar notation: V A 1-bit flag indicating that the valid lifetime of the New Prefix MUST be effectively decremented in real time. P A 1-bit flag indicating that the preferred lifetime of the New Prefix MUST be effectively decremented in real time. (Section 3.2.1.2) The current PD draft implicitly assumes the (not-yet-introduced) additional flags are on, while these bits are off in the current typical cases. Before going that further, however, I still think it is overkilling for the delegating router to have the ability to control the downstream lifetimes. IMO, the requesting router (and the site's administrator) should be responsible for such parameters, with one trivial constraint: the site lifetimes must not be smaller than the lifetimes of each downstream link. In summary, I first would like to make a consensus if we need to allow the requesting router to have the ability to control the downstream lifetimes. As I said above, I'm negative on this. If our consensus is to allow the delegating router to have the ability, it's okay. Then, 1. the requesting router should also have the additional bits (like P and V above), 2. (this may be controversial) the lifetimes in router advertisement on each downstream link should be the same as the default of RFC 2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT decreasing in real time), as long as Renew/Reply exchanges succeed, and 3. in any case, the valid lifetime of a prefix delegated by PD must not be smaller than the valid lifetime in router advertisements on any downstream link. Note that, as a consequence of 2 and 3, the default value of the valid lifetime in a PD prefix option must be larger than AdvValidLifetime. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Multipart_Thu_Mar__6_15:25:58_2003-1-- -------------------------------------------------------------------- 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 Mar 5 23:13:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267Do7f023112; Wed, 5 Mar 2003 23:13:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h267DnAL023111; Wed, 5 Mar 2003 23:13:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267Dj7f023104 for ; Wed, 5 Mar 2003 23:13:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h267Drvx003727 for ; Wed, 5 Mar 2003 23:13:53 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00242 for ; Thu, 6 Mar 2003 00:13:48 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:13:47 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:11:45 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:13:47 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:13:46 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A311015210; Thu, 6 Mar 2003 16:14:29 +0900 (JST) Date: Thu, 06 Mar 2003 16:14:05 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 89 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>> Ole Troan said: >> 2. Section 11.1 now specifies the requesting router to use >> Rebind/Reply exchanges to verify an existing binding (instead of >> Renew/Reply exchanges). According to the very recent >> clarifications on the base DHCPv6 spec, however, I'm not sure if >> Rebind is appropriate here; the server should drop the Rebind >> message unless it has an explicit knowledge about the validity or >> invalidity of the prefix, which should not be the case (e.g.) when >> the upstream link flaps. > Rebind now behaves just like Confirm. if by link flap you mean change > of link to another delegating router, the delegating router can reply > to a Rebind even without a binding if it knows through explicit > configuration that the prefixes in the IA_PD is not valid for the link. Are you referring to the following part of draft-ietf-dhc-dhcpv6-interop-00.txt? 1. Response of servers to Renew and Rebind messages, sections 18.2.3 and 18.2.4 Resolution: Leave the sentence in section 18.2.3 unchanged. Replace the sentence in section 18.2.4 with the following text: If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to zero. This Reply constitutes an explicit notification to the client that the addresses in the IA are no longer valid. In this situation, if the server does not send a Reply message it silently discards the Rebind message. The problem here is that this is a MAY requirement and that "explicit configuration information" is ambiguous. Since this is a MAY, the delegating router (i.e. server) MAY NOT send a Reply message, which will cause a bad effect (that the invalid prefix is going to be used). For the case of address assignment, this should be a minor issue, because this situation only happens when none of the events to issue a Confirm happen but the upstream router has somehow been swapped. For the PD case, however, we don't have Confirm/Reply exchanges. So the requirement level should be stronger enough. The same argument should apply to the ambiguous of the wording "explicit configuration information". In my understanding, the author intentionally uses an ambiguous term because this is a very minor case and there can be a (unidentified) trick to build the explicit information, e.g., a background communication between a primary server and a secondary one. Again, for the PD case, this is more likely to happen, so we need to be specific enough. Thus, I would suggest to add the following text (or something like this) to the delegating router behavior: If the delegating router cannot find a requesting router entry for the IA_PD and the delegating router determines that the prefixes in the IA_PD are not appropriate for the requesting router according to the delegating router's explicit configuration information, the delegating router SHOULD send a Reply message to the requesting router containing the requesting router's IA_PD, with the lifetimes for the prefixes in the IA_PD set to zero. This Reply constitutes an explicit notification to the requesting router that the prefixes in the IA_PD are no longer valid. The explicit configuration information of the delegating router contains the fact that the proposed prefixes from the requesting router is not covered by a prefix for the organization of the delegating router. In summary, I propose to change MAY to SHOULD and to add a concrete example of "explicit configuration information." It would also be helpful to describe how the requesting should react to this event. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 5 23:17:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267Ho7f023192; Wed, 5 Mar 2003 23:17:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h267Hoej023191; Wed, 5 Mar 2003 23:17:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267Hj7f023178 for ; Wed, 5 Mar 2003 23:17:45 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h267HsYt028654 for ; Wed, 5 Mar 2003 23:17:54 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01304 for ; Wed, 5 Mar 2003 23:17:48 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:17:45 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:17:45 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:17:45 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:17:44 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id AB8AA15210; Thu, 6 Mar 2003 16:18:27 +0900 (JST) Date: Thu, 06 Mar 2003 16:18:03 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: NoPrefixAvail against Solicit (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>> Ole Troan said: >> 3. Section 10.2 contains the following sentence (newly added in the >> latest revision): >> >> If the delegating router cannot delegate any prefixes to an IA_PD in >> the message from the requesting router, the delegating router MUST >> include the IA_PD in the Reply message with no prefixes in the IA_PD >> and a Status Code option in the IA_PD containing status code >> NoPrefixAvail. >> >> I guess the "Reply" should be "Advertisement" here, because this >> section is talking about "Delegating Router Solicitation." I also >> guess the sentence was added in response to a question of mine in >> the ML. If so, a similar clarification should be introduced to >> Section 11.2 as well. Additionally, the corresponding client >> behaviors should also be documented. > yes, well spotted. After re-reading the draft, I now believe this part is just invalid in Section 10.2 and should be moved to somewhere in Section 11.2. In fact, NoPrefixAvail in Advertise against Solicit is already documented in the last paragraph of Section 10.2 JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 5 23:35:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267Zo7f023633; Wed, 5 Mar 2003 23:35:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h267ZolU023632; Wed, 5 Mar 2003 23:35:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267Zj7f023625 for ; Wed, 5 Mar 2003 23:35:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h267Zsvx008703 for ; Wed, 5 Mar 2003 23:35:54 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11110 for ; Thu, 6 Mar 2003 00:35:48 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:35:48 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:35:48 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:35:48 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:35:47 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7DC8C15210; Thu, 6 Mar 2003 16:36:30 +0900 (JST) Date: Thu, 06 Mar 2003 16:36:06 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: DHCPv6 clarification draft and PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5r89tut8y.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>> Ole Troan said: >> 4. The PD draft should reflect some parts of >> draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections >> 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. > I have made the changes where appropriate, i.e where we already have > cut and pasted text from the DHCPv6 base specification. I don't think it's enough. For example, Section 8 of prefix-delegation-02 is almost the exact copy of Section 22.4 of dhcpv6-28, with s/IA_NA/IA_PD/g and s/address/prefix/g. Since Section 2 of dhcpv6-interop-00 proposes to "add" paragraphs to Section 22.4 of dhcpv6-28, corresponding paragraphs should be added to Section 8 of prefix-delegation. I've not gone thorough the entire issues of the interop draft, but I'm quite sure that there still exist similar cases. (If you are not convinced, I'll try to make a complete list.) >> We may be able to omit some of them as trivial clarifications, but >> we should reflect some other part of them because the base DHCPv6 >> spec (and thus the clarifications for it) is too specific to >> address assignment. In some cases, implementors can use analogy of >> the base spec to implement the PD draft, but we should basically >> provide comprehensive information in the PD draft itself to ensure >> better interoperability. (As some people, including me, have >> repeatedly pointed out, the best approach would be to make the base >> spec generic so that each stateful method can just refer to the >> base spec. Since we could not make it due to the "it's too late" >> reason, we should be responsible to implementors for providing >> detailed information within the PD specification). > the PD specification is not meant to be complete and needs to be read > in conjunction with the base DHCP specification. I know (and agree), but I'm saying the PD specification should be clear wherever a difference between address assignment and prefix delegation exist. We should be rather redundant than leave the difference ambiguous. At least please reconsider each issue in the interop draft and merge necessary changes from it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 5 23:50:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267o27f023891; Wed, 5 Mar 2003 23:50:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h267o1x9023890; Wed, 5 Mar 2003 23:50:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h267nw7f023883 for ; Wed, 5 Mar 2003 23:49:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h267o6vx011281 for ; Wed, 5 Mar 2003 23:50:07 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28484 for ; Thu, 6 Mar 2003 00:50:01 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:50:00 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:47:58 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:50:00 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 07:50:00 Z Content-class: urn:content-classes:message Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Mar 2003 23:49:59 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045488@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Thread-Index: AcLjOW7HgcJ62qhVQmOXOS5ozvER7QAez/aQ From: "Michel Py" To: "Brian Carpenter" Cc: "Bob Hinden & Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h267nw7f023884 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian E Carpenter wrote: > My concerns were handled in the various rounds between > the authors (mainly by taking stuff out, which is what > the WG asked for anyway). Ship it. Michel. -------------------------------------------------------------------- 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 Mar 6 00:43:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h268hU7f024223; Thu, 6 Mar 2003 00:43:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h268hTBx024222; Thu, 6 Mar 2003 00:43:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h268hQ7f024215 for ; Thu, 6 Mar 2003 00:43:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h268hYvx026447 for ; Thu, 6 Mar 2003 00:43:34 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15186 for ; Thu, 6 Mar 2003 01:43:28 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 08:43:28 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 08:43:28 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 08:43:27 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 08:43:27 Z Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Mar 2003 00:43:27 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C73@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Thread-Index: AcLjOysiFtkmxWH4Sa+W5gQrrcy9mQAgF9xw From: "Michel Py" To: "Pekka Savola" , "Brian Carpenter" Cc: "Bob Hinden" , "Margaret Wasserman" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h268hQ7f024216 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > My perception is that the /48 "border" is inside the IANA > delegation. It is, but read the text again: | An example of the resulting format of global unicast address ^^^^^^^ This example is what the Best Current Practice is today. "Current" means what it means: it might change later, but as of today it's the deal. I still think this should be published as BCP. Several people have contributed that we needed to send a "strong message". Michel. -------------------------------------------------------------------- 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 Mar 6 01:08:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2698J7f024476; Thu, 6 Mar 2003 01:08:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2698I2t024475; Thu, 6 Mar 2003 01:08:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2698E7f024468 for ; Thu, 6 Mar 2003 01:08:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2698LYt019758 for ; Thu, 6 Mar 2003 01:08:22 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17603 for ; Thu, 6 Mar 2003 02:08:11 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:07:59 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:07:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:07:58 Z Received: from c001.snv.cp.net ([209.228.32.135] [209.228.32.135]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:07:58 Z Received: (cpmta 25477 invoked from network); 6 Mar 2003 01:07:56 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.135) with SMTP; 6 Mar 2003 01:07:56 -0800 X-Sent: 6 Mar 2003 09:07:56 GMT Message-Id: <011f01c2e3c0$0f9a4670$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <963621801C6D3E4A9CF454A1972AE8F54C73@server2000.arneill-py.sacramento.ca.us> Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Date: Thu, 6 Mar 2003 11:09:12 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I tend to agree with the previsous comment that people will take this example as law and will make it a defacto standard boarder even if we only intened to make it a sample based on one groups implementation. I would suggest that it read somthing to the effect of: An example of the resulting format of global unicast address based on the IANA implementation... Eric ----- Original Message ----- From: "Michel Py" To: "Pekka Savola" ; "Brian Carpenter" Cc: "Bob Hinden" ; "Margaret Wasserman" ; Sent: Thursday, March 06, 2003 10:43 AM Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt > > Pekka Savola wrote: > > My perception is that the /48 "border" is inside the IANA > > delegation. > > It is, but read the text again: > > | An example of the resulting format of global unicast address > ^^^^^^^ > > This example is what the Best Current Practice is today. "Current" means > what it means: it might change later, but as of today it's the deal. I > still think this should be published as BCP. Several people have > contributed that we needed to send a "strong message". > > Michel. > > > -------------------------------------------------------------------- > 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 Thu Mar 6 01:17:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h269Ht7f024689; Thu, 6 Mar 2003 01:17:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h269HtYW024688; Thu, 6 Mar 2003 01:17:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h269Ho7f024678 for ; Thu, 6 Mar 2003 01:17:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h269HwYt021552 for ; Thu, 6 Mar 2003 01:17:58 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29681 for ; Thu, 6 Mar 2003 02:17:53 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:17:52 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:17:52 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:17:52 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:17:51 Z Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Mar 2003 01:17:50 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504548F@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Thread-Index: AcLjwIudWAItCv0jRhKFW65odAvFwAAAD2cg From: "Michel Py" To: "EricLKlein" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h269Hp7f024679 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > EricLKlein wrote: > IANA implementation IANA "implementation"? What does this mean? Can you give an example of something that the IANA has implemented? Michel. -------------------------------------------------------------------- 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 Mar 6 01:33:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h269Xq7f025101; Thu, 6 Mar 2003 01:33:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h269Xqdq025100; Thu, 6 Mar 2003 01:33:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h269Xm7f025093 for ; Thu, 6 Mar 2003 01:33:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h269Xvvx006360 for ; Thu, 6 Mar 2003 01:33:57 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18161 for ; Thu, 6 Mar 2003 01:33:50 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:33:49 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:33:49 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:33:49 Z Received: from c001.snv.cp.net ([209.228.32.134] [209.228.32.134]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 09:33:48 Z Received: (cpmta 9100 invoked from network); 6 Mar 2003 01:33:46 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.134) with SMTP; 6 Mar 2003 01:33:46 -0800 X-Sent: 6 Mar 2003 09:33:46 GMT Message-Id: <016a01c2e3c3$ab55a5c0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <963621801C6D3E4A9CF454A1972AE8F504548F@server2000.arneill-py.sacramento.ca.us> Subject: Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Date: Thu, 6 Mar 2003 11:35:02 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This was a comment strictly based on what I understood from the thread in this conversation, the /48 was based on the IANA implementation. This is how I understood the lines: > My perception is that the /48 "border" is inside the IANA > delegation. But apparently I am mixing up two diffrent e-mail chains,in the other one there was a comment by you: > In other words: documenting APNIC policy is nice, APNIC deserves kudos > for assigning a /32 to the purpose of documentation prefixes, and your > draft should, if possible, go further than what is already there but > ship as-is if nothing new is on the horizon. I am sorry but I seem to have gotten my messages mixed. Eric ----- Original Message ----- From: "Michel Py" To: "EricLKlein" ; Sent: Thursday, March 06, 2003 11:17 AM Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt > EricLKlein wrote: > IANA implementation IANA "implementation"? What does this mean? Can you give an example of something that the IANA has implemented? Michel. -------------------------------------------------------------------- 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 Mar 6 02:03:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26A337f025600; Thu, 6 Mar 2003 02:03:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26A33YU025599; Thu, 6 Mar 2003 02:03:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26A307f025592 for ; Thu, 6 Mar 2003 02:03:00 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26A38vx011535 for ; Thu, 6 Mar 2003 02:03:08 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04604 for ; Thu, 6 Mar 2003 02:03:02 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:03:00 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:03:00 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:03:00 Z Received: from mta0 ([61.144.161.2] [61.144.161.2]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:02:59 Z Received: from ArchanaCL1172 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HBB002R2NU52U@mta0.huawei.com> for ipng@sunroof.eng.sun.com; Thu, 06 Mar 2003 18:01:20 +0800 (CST) Date: Thu, 06 Mar 2003 15:31:44 +0530 From: Archana Subject: which prefix is to be used ? To: ipng@sunroof.eng.sun.com Reply-to: archana_p@huawei.com Message-Id: <000201c2e3c7$65515020$db04120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_zKO6gvNe0nr7zeprVwZVTQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_zKO6gvNe0nr7zeprVwZVTQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Can there be a situation like this - -> where a V6 cloud is connected by NAT-PT router (say R1) to a V4 cloud (V4-1) -> the same V6 cloud is connected by another NAT-PT router ( say R2 ) to another V4 cloud (V4-2) Assuming there is a network like that when a V6 node has to communicate with a V4 node in V4-1 how will the V6 node know which prefix to use (the one sent by R1 or R2) ? Please clarify Regards Archana --Boundary_(ID_zKO6gvNe0nr7zeprVwZVTQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Hi

Can there be a situation like this -

-> where a V6 cloud is connected by NAT-PT router (say R1) to a V4 cloud (V4-1)

-> the same V6 cloud is connected by another NAT-PT router ( say R2 ) to another V4 cloud (V4-2)

Assuming there is a network like that when a V6 node has to communicate with a V4 node in V4-1

how will the V6 node know which prefix to use (the one sent by R1 or R2) ?

Please clarify

Regards

Archana

 

 

--Boundary_(ID_zKO6gvNe0nr7zeprVwZVTQ)-- -------------------------------------------------------------------- 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 Mar 6 02:03:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26A3s7f025623; Thu, 6 Mar 2003 02:03:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26A3sT0025622; Thu, 6 Mar 2003 02:03:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26A3o7f025615 for ; Thu, 6 Mar 2003 02:03:50 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26A3wYt028837 for ; Thu, 6 Mar 2003 02:03:58 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06544 for ; Thu, 6 Mar 2003 02:03:53 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:03:52 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:03:47 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:03:42 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:03:42 Z Content-class: urn:content-classes:message Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Mar 2003 02:03:41 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C76@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt Thread-Index: AcLjw+Y8sg4szyN0QYO+rpN96T369wAAFADg From: "Michel Py" To: "EricLKlein" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h26A3o7f025616 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, > EricLKlein wrote: > This was a comment strictly based on what I understood from > the thread in this conversation, the /48 was based on the > IANA implementation. Not at all. This is a matter of semantics. First, the use of the word "implementation" in this context (associated to IANA) is terrible. Second, the /48 is not directly based on IANA anything. The /48 currently is RIR recommended assignment policy, and RIR policies WRT this have been greatly inspired by RFC3177 (an IAB/IESG, not IANA, document). > Pekka Savola wrote: > My perception is that the /48 "border" is inside the > IANA delegation. I'm afraid this is not the clearest sentence that the talented Pekka has written. Although it might be technically correct, it takes many shortcuts. The /48 is assigned to a site by a LIR. The LIR gets its space for a NIR or a RIR, and the RIRs are delegated space by IANA. What Pekka meant by "inside the IANA delegation" was "not part of the architecture", I believe. The topic here is the removal of the SLA boundary from the architecture, while the IID boundary remains part of it. Michel. -------------------------------------------------------------------- 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 Mar 6 02:07:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26A7q7f025830; Thu, 6 Mar 2003 02:07:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26A7qHr025829; Thu, 6 Mar 2003 02:07:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26A7m7f025819 for ; Thu, 6 Mar 2003 02:07:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26A7uvx012457 for ; Thu, 6 Mar 2003 02:07:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02319 for ; Thu, 6 Mar 2003 03:07:51 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:07:51 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:07:49 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:07:49 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:07:49 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26A7cg15034; Thu, 6 Mar 2003 12:07:38 +0200 Date: Thu, 6 Mar 2003 12:07:37 +0200 (EET) From: Pekka Savola To: Bob Hinden & Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Draft IPv6 working group charter In-Reply-To: <4.3.2.7.2.20030305143621.02332bc0@mailhost.iprg.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Mar 2003, Bob Hinden & Margaret Wasserman wrote: > Attached is a copy of the charter we sent to the Internet ADs. .. minus the dns discovery work.. Charter looks pretty good. A comment: - Complete work on Scoped Addressing Architecture and publish. ==> this will probably stay in limbo until some closure is reached about site-local addressing, so putting it in a charter (as it depends on the site-local course) may be a bit premature -- but ok if not too many cycles are used for it now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 02:37:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26AbB7f026421; Thu, 6 Mar 2003 02:37:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26AbBUd026420; Thu, 6 Mar 2003 02:37:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Ab77f026413 for ; Thu, 6 Mar 2003 02:37:07 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26AbGvx017797 for ; Thu, 6 Mar 2003 02:37:16 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26325 for ; Thu, 6 Mar 2003 02:37:10 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:37:09 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:37:09 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:37:08 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:37:08 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26Ab6415271; Thu, 6 Mar 2003 12:37:07 +0200 Date: Thu, 6 Mar 2003 12:37:06 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: bzill@microsoft.com Subject: zill-ipv6wg-zone-prefixlen-00 comments Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few comments on the individual submission. big issues: ----------- ==> note to self and to the w.g.: this is very similar to Bellovin's access-prefix draft, but simpler (with advantages / drawbacks that result from that). So, I believe it might be useful to try to compare these two approaches so we could better understand which features are needed and which are net. ==> note that if one sets the O field to 1 but forgets to set "Org PrefixLen", org prefixlen defaults to zero, and makes all of the Internet a trusted, "in-organization" zone (as the field was previously reserved"). This must be stated in the security considerations. I would also recommend that the prefix length "0" in conjunction with O-bit=0 is a special value which MUST be treated as equal to "none", and a possible error be logged. This reduces the amount of flexibility slightly, but the tradeoff seems too huge, otherwise. 5. Security Considerations ==> it should be noted that a single on-off binary value in-org,outside-of-org may not be granular/flexible enough, and that as many attacks come from inside the organization (either by an insider attack or breaking into a system in the organization and attacking there), depending too heavily on security of the "in-organization" may not be a good idea. substantial/semi-editorial: --------------------------- Option format to allow the router to also advertise the length of the advertised prefix which belongs to the same organization (or other administrative entity). ==> clarify "other administrative entity", think the point here was to say like "not necessary the same organization, but also otherwise named, *same* administrative entity"? ==> if not, this may require syncing elsewhere in the draft (where it discusses same-org, same-admin-entity) editorial: ---------- IPv6 Working Group Brian Zill Internet Draft Microsoft ==> "IPv6 WG" is premature as this is not yet a w.g. document..? ==> the whole document should be shifted 5 characters to the left; it exceeds the maximum line length. References ==> split the references explicitly, even though those are probably all Normative. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 02:41:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Afr7f026570; Thu, 6 Mar 2003 02:41:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26Afqow026567; Thu, 6 Mar 2003 02:41:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Afn7f026559 for ; Thu, 6 Mar 2003 02:41:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26Afvvx018662 for ; Thu, 6 Mar 2003 02:41:57 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22097 for ; Thu, 6 Mar 2003 03:41:52 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:41:51 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:41:51 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:41:51 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 10:41:51 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26AfnH15343; Thu, 6 Mar 2003 12:41:49 +0200 Date: Thu, 6 Mar 2003 12:41:49 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: bzill@microsoft.com Subject: Re: zill-ipv6wg-zone-prefixlen-00 comments In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 6 Mar 2003, Pekka Savola wrote: > I would also recommend that the prefix length "0" in conjunction with > O-bit=0 is a special value which MUST be treated as equal to "none", I meant O-bit=1, of course. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 03:20:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26BKw7f027073; Thu, 6 Mar 2003 03:20:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26BKwJG027072; Thu, 6 Mar 2003 03:20:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26BKt7f027065 for ; Thu, 6 Mar 2003 03:20:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26BL2Yt012706 for ; Thu, 6 Mar 2003 03:21:03 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07641 for ; Thu, 6 Mar 2003 04:20:57 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:19:33 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:17:30 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:19:33 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:19:32 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h26BJILD057618; Thu, 6 Mar 2003 12:19:18 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h26BJHcT106642; Thu, 6 Mar 2003 12:19:17 +0100 Received: from gsine03.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49184 from ; Thu, 6 Mar 2003 12:19:08 +0100 Message-Id: <3E6723FD.4829B158@hursley.ibm.com> Date: Thu, 06 Mar 2003 11:33:33 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: trusting end-nodes to do the right thing [Re: IPv6 w.g. Last Callon "IPv6 Flow Label Specification"] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > We may be treading into a very difficult situation (in some ways similar > to why MIPv6 got pushback from the IESG, IMO), and to be pre-emptive, I'd > really appreciate if folks would have a look at the particular issue (at > the end of the mail) and think whether it is a problem or not. The flow label has been a forgeable field since IPSEC decided to leave it outside the crypto calculation. I'd be very happy if this decision could be reversed, since the field is immutable, but I don't think that is realistic. IMHO the IESG would have no grounds for raising this now; it derives automatically from ancient decsions. I agree that we should get a security person to look at your comments, but unless anyone else supports your concern, it's my impression that you are worrying about something we cannot change anyway. The security considerations simply document facts of life. Brian > > On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > > The 3-tuple of the Flow Label and the Source and Destination Address > > > fields enables efficient IPv6 flow classification, where only IPv6 > > > main header fields in fixed positions are used. > > > > > > ==> this might require some extra analysis somewhere (not in that > > > particular place, I think). In particular, this seems to say that once > > > this is published people can happily move to using the three-tuple > > > classification. The reality is probably quite different, and one must > > > also consider the big portion of nodes which do not mark the flows. > > > > The goal of this document is not to describe use cases. It is > > to set the minimum conditions hosts and routers must meet. I do > > not believe we should add use cases to this document. > > I believe the original text does not give a realistic picture of the > situation. > > For the purpose of minimum conditions, the text could be removed > altogether, of course -- that would be fine by me. I could also live with > (by a thread :-) the current version, but I really believe it should be > changed slightly. > > > > To enable applications and transport protocols to define what packets > > > constitute a flow, the source node MUST provide means for the > > > applications and transport protocols to specify the Flow Label values > > > to be used with their flows. > > > > > > ==> this requirement seems unacceptable at the moment. This clearly > > > requires (at least) de-facto API so applications could set Flow Label > > > values -- and as such does not exist. If it did (and I believe there's > > > work in progress), there would *have to be* a normative reference to it). > > > So, clearly a MUST seems to a big no-no. > > > > But this is a statement about what hosts must do to make the flow label > > useful. > > No, that's not correct, or either of us is misunderstanding the paragraph > above (if so, a wording change is needed). > > The nodes (kernel, in particular) are able to mark flows by itself, > without any interaction from the applications -- so having apps have a > MUST possibility to influence the flow labeling is undoubtedly useful, but > certainly not something requiring MUST, considering the current situation. > > Note: I'd argue for MUST myuself if we had had a standard (or even > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > year before this being sent to the IESG. > > > If you want to standardize a socket API extension that's fine, > > the Open Group exists for that. However, I believe a MUST is needed. > > A MUST without a means is bad practise, IMO. > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > is currently using or has recently used when creating new flows. Flow > > > Label values previously used with a specific pair of source and > > > destination addresses MUST NOT be assigned to new flows with the same > > > address pair within 120 seconds of the termination of the previous > > > flow. > > > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > > value which was previously used, and send the packet, the operating system > > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > > s/reuse/unintentionally reuse/, or some other rewording? > > > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > > we included an algorithm, but the WG wanted it removed, so we removed it. > > Yes, the stack can do it easily -- no doubt about that -- but it's > *wrong*; this is connected to the security issue, below. > > > > To enable co-existence of different methods in IPv6 nodes, the > > > methods MUST meet the following basic requirements: > > > > > > ==> this and the following points seem a little oddly placed in this memo: > > > they seem out-of-place, as the rest of the memo seems to concentrate on > > > entirely different issues. Personally I view specifying how source nodes > > > should label flows one thing, and the rest entirely another. But I can > > > live with these, even though I think they're more fit to a non-standards > > > track document. > > > > Then you don't want a change here? > > I can live without it -- waiting to hear others' opinions -- but I think > the source node behaviour is entirely different issue from the network > treatment. > > > > 5.1 Theft and Denial of Service > > > > > > ==> this section mainly deals with issues relating to forging all of the > > > source,destination,label three-tuple (exception is the last paragraph, > > > which deals with a trusted-node-but-untrusted-user/application case), > > > which protects mainly against a DoS attack (resource depletion). > > > > > > This seems to overlook the most important part: the typical model today is > > > that operators perform differentiation of flows *themselves*: this > > > document proposes to shift that, *over an administrative boundary*, to the > > > source nodes, which suddenly become trusted to do the right thing. > > > > No, it adds the *labelling* of flows to the source, as a new capability. > > The labeling with current "service model" leads to differentiation. I'll > try to reword it again below. If the "service model" would be such that > the source node is *not* expected to label flows correctly, I'd certainly > agree. > > > It says *nothing* about how differentiation is done. That is indeed > > a separate and quite complex discussion, that will keep the QOS > > community busy for years. > > I believe a bit similar arguments were on the table when mobileip working > group proposed MIPv6 to the IESG, and it got pushed down, as "doesn't > work, be more specific". That was some 2-3 years ago, and only now MIPv6 > is nearing completion. > > I'd rather handle these kind of issues before IESG, if possible. > > The problems are different, but there seem to be some dangerous common > elements. > > > The idea is to keep that discussion out > > of the IPv6 WG, by defining the boundary conditions here, so that > > the flow label becomes a viable tool for differentiation downstream. > > My fear is that false assumptions lead to wrong conclusions and broken > tools, and wasted effort (both from IPv6 wg and especially from the > follow-up wgs). > > > I think this was clear in the previous WG discussions. > > Unfortunately, the flood was so huge at a point that I couldn't keep up > (because I didn't really even care, except whether WG would go on a course > which seems really problematic, like now) > > > > This would be equivalent to replacing network ingress filtering (to drop > > > packets with forged source addresses) to a requirement for nodes to allow > > > out only packets which include their own source address. > > > > > > (By the way, do > > you think nodes *should* be allowed to forge the source address?) > > I'll answer this first. > > The nodes certainly should be allowed (in the kernel level) to forge the > source addresses: any model which forces this is broken. > > The reason for breakage is that such a model assumes that the nodes behave > "properly". For most cases, that is correct. But because there is still > a huge number of systems behaving differently, you cannot depend on it, > and assuming it is being done would be wrong. > > The right (my humble POV, of course :-) answers to your question are: > > - no, the user privileged process on a node should not be able to set the > source address (no problem today) > - no, the *network* where the node is attached to should not allow the > user to forge the source address (note: different administrative entity) > > > No. The checks can perfectly well be applied at ISP ingress. > > Yes, but as the first comment seems to show, in practise this checking > would be de-facto removed for performance etc. reasons. > > > I did want to include more aggressive text about ingress > > filtering, but in fact it would be out of place. > > I'm not sure which kind of text you're referring to, but IMO ingress > filtering misses the biggest point. > > > > Needless to say this seems to indicate a major oversight of the > > > security/operational reality. I'd be very surprised if this was not > > > pushed back in the IESG unless this caveat is very explicitly documented. > > > > I think your interpretation is quite wrong, but we can certainly ask a > > security expert or two. > > Ok. > > To try to clarify what I meant, let me try to explain it again. > > Any model that requires that source nodes prevent the root/administrator > from willingly doing something, and more or less *depending on that* is > broken. > > Let me try to give an example. When Windows XP was being published, some > very popular magazines were writing about their belief that adding "raw > sockets" functionality would be catastrophic for the Internet, degrade > security as people could "now" send any kind of packets they'd want etc. > The reality was entirely different. Such can be done *anyway*, using > other implementations, using different mechanisms to achieve the same > goal, etc. > > This is a similar issue. Given an *untrusted* node, specifying mechanisms > which try to make the *untrusted* node do something you'd like to trust > (to a rather full extent) seems *completely* bogus.. > > Certainly, one should specify checks that user-mode applications MUST NOT > be able to re-use flow labels within a lifetime, but that's entirely > different from the approach in the draft. > > Certainly, this is a very problematic issue (which was thought to be > solved later, in some other w.g.). I'm not requiring it be solved here. > But I'm requiring that we don't pass the problem on without stating *very* > explicitly the issues why it might/might not work properly -- so that any > followup efforts that might start to build QoS mechanisms on this would > not start with an entirely different set of assumptions (easily leading to > wrong conclusions and broken tools). > > I'm not sure if I managed to make the point any clearer, I hope so. > > I'd also really appreciate comment on this viewpoint (for or against :-) > from everybody. > > Especially those with (ISP) operator [the "customer of the IETF" in this > instance] or security background would be encouraged to speak up. :-) > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 03:21:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26BLH7f027101; Thu, 6 Mar 2003 03:21:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26BLHqd027100; Thu, 6 Mar 2003 03:21:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26BLB7f027093 for ; Thu, 6 Mar 2003 03:21:11 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26BLIvx025836 for ; Thu, 6 Mar 2003 03:21:18 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09580 for ; Thu, 6 Mar 2003 04:21:12 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:21:11 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:21:11 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:21:11 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:21:10 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26BKvj15642; Thu, 6 Mar 2003 13:20:57 +0200 Date: Thu, 6 Mar 2003 13:20:56 +0200 (EET) From: Pekka Savola To: Michel Py cc: Brian Carpenter , Bob Hinden , Margaret Wasserman , Subject: RE: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C73@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 6 Mar 2003, Michel Py wrote: > > Pekka Savola wrote: > > My perception is that the /48 "border" is inside the IANA > > delegation. > > It is, but read the text again: > > | An example of the resulting format of global unicast address > ^^^^^^^ > > This example is what the Best Current Practice is today. "Current" means > what it means: it might change later, but as of today it's the deal. I > still think this should be published as BCP. Several people have > contributed that we needed to send a "strong message". The main purpose of this document is to move *RFC2374* to Historic (and at the same thime, explain the reasons for doing so). Advocation is a separate issue entirely. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 03:33:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26BX27f027798; Thu, 6 Mar 2003 03:33:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26BX1uf027797; Thu, 6 Mar 2003 03:33:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26BWw7f027790 for ; Thu, 6 Mar 2003 03:32:58 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26BX6vx028797 for ; Thu, 6 Mar 2003 03:33:06 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00253 for ; Thu, 6 Mar 2003 03:33:00 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:32:59 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:32:59 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:32:59 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:32:58 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26BWus15749; Thu, 6 Mar 2003 13:32:56 +0200 Date: Thu, 6 Mar 2003 13:32:55 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: trusting end-nodes to do the right thing [Re: IPv6 w.g. Last Callon "IPv6 Flow Label Specification"] In-Reply-To: <3E6723FD.4829B158@hursley.ibm.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 6 Mar 2003, Brian E Carpenter wrote: > Pekka Savola wrote: > > > > We may be treading into a very difficult situation (in some ways similar > > to why MIPv6 got pushback from the IESG, IMO), and to be pre-emptive, I'd > > really appreciate if folks would have a look at the particular issue (at > > the end of the mail) and think whether it is a problem or not. > > The flow label has been a forgeable field since IPSEC decided to leave > it outside the crypto calculation. I'd be very happy if this decision > could be reversed, since the field is immutable, but I don't think that > is realistic. IMHO the IESG would have no grounds for raising this now; > it derives automatically from ancient decsions. The use of IPsec seems irrelevant for the *ISP* as they can't verify it -- no help there. The problem is of trying to make untrusted end-nodes trusted to label the flows properly. Changing IPsec will not help (except if you assume communication is to e.g. ISP's own servers, middleboxes etc.). > I agree that we should get a security person to look at your comments, but > unless anyone else supports your concern, it's my impression that you are > worrying about something we cannot change anyway. There are two most major issues here: 1) something we should change 2) something we must document if we cannot change I'm requiring at least 2). > The security considerations > simply document facts of life. Unfortunately, the security considerations as of now *does not* document these facts of life. This is the biggest concern. Of course, I strongly also want to change the model slightly (e.g. the MUST requirement for nodes not to send out used flow lables), to make it the restrictions of the model clearer. This does not yet fix the core problem, how the ISP can make anything of these labels -- trust them -- but at least now the starting assumptions are closer to correct. The extreme case would be taking a full halt here for all of the flow label draft, working out the details, and only then publishing it. I don't think this is correct approach for now. > > On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > > > The 3-tuple of the Flow Label and the Source and Destination Address > > > > fields enables efficient IPv6 flow classification, where only IPv6 > > > > main header fields in fixed positions are used. > > > > > > > > ==> this might require some extra analysis somewhere (not in that > > > > particular place, I think). In particular, this seems to say that once > > > > this is published people can happily move to using the three-tuple > > > > classification. The reality is probably quite different, and one must > > > > also consider the big portion of nodes which do not mark the flows. > > > > > > The goal of this document is not to describe use cases. It is > > > to set the minimum conditions hosts and routers must meet. I do > > > not believe we should add use cases to this document. > > > > I believe the original text does not give a realistic picture of the > > situation. > > > > For the purpose of minimum conditions, the text could be removed > > altogether, of course -- that would be fine by me. I could also live with > > (by a thread :-) the current version, but I really believe it should be > > changed slightly. > > > > > > To enable applications and transport protocols to define what packets > > > > constitute a flow, the source node MUST provide means for the > > > > applications and transport protocols to specify the Flow Label values > > > > to be used with their flows. > > > > > > > > ==> this requirement seems unacceptable at the moment. This clearly > > > > requires (at least) de-facto API so applications could set Flow Label > > > > values -- and as such does not exist. If it did (and I believe there's > > > > work in progress), there would *have to be* a normative reference to it). > > > > So, clearly a MUST seems to a big no-no. > > > > > > But this is a statement about what hosts must do to make the flow label > > > useful. > > > > No, that's not correct, or either of us is misunderstanding the paragraph > > above (if so, a wording change is needed). > > > > The nodes (kernel, in particular) are able to mark flows by itself, > > without any interaction from the applications -- so having apps have a > > MUST possibility to influence the flow labeling is undoubtedly useful, but > > certainly not something requiring MUST, considering the current situation. > > > > Note: I'd argue for MUST myuself if we had had a standard (or even > > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > > year before this being sent to the IESG. > > > > > If you want to standardize a socket API extension that's fine, > > > the Open Group exists for that. However, I believe a MUST is needed. > > > > A MUST without a means is bad practise, IMO. > > > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > > is currently using or has recently used when creating new flows. Flow > > > > Label values previously used with a specific pair of source and > > > > destination addresses MUST NOT be assigned to new flows with the same > > > > address pair within 120 seconds of the termination of the previous > > > > flow. > > > > > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > > > value which was previously used, and send the packet, the operating system > > > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > > > s/reuse/unintentionally reuse/, or some other rewording? > > > > > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > > > we included an algorithm, but the WG wanted it removed, so we removed it. > > > > Yes, the stack can do it easily -- no doubt about that -- but it's > > *wrong*; this is connected to the security issue, below. > > > > > > To enable co-existence of different methods in IPv6 nodes, the > > > > methods MUST meet the following basic requirements: > > > > > > > > ==> this and the following points seem a little oddly placed in this memo: > > > > they seem out-of-place, as the rest of the memo seems to concentrate on > > > > entirely different issues. Personally I view specifying how source nodes > > > > should label flows one thing, and the rest entirely another. But I can > > > > live with these, even though I think they're more fit to a non-standards > > > > track document. > > > > > > Then you don't want a change here? > > > > I can live without it -- waiting to hear others' opinions -- but I think > > the source node behaviour is entirely different issue from the network > > treatment. > > > > > > 5.1 Theft and Denial of Service > > > > > > > > ==> this section mainly deals with issues relating to forging all of the > > > > source,destination,label three-tuple (exception is the last paragraph, > > > > which deals with a trusted-node-but-untrusted-user/application case), > > > > which protects mainly against a DoS attack (resource depletion). > > > > > > > > This seems to overlook the most important part: the typical model today is > > > > that operators perform differentiation of flows *themselves*: this > > > > document proposes to shift that, *over an administrative boundary*, to the > > > > source nodes, which suddenly become trusted to do the right thing. > > > > > > No, it adds the *labelling* of flows to the source, as a new capability. > > > > The labeling with current "service model" leads to differentiation. I'll > > try to reword it again below. If the "service model" would be such that > > the source node is *not* expected to label flows correctly, I'd certainly > > agree. > > > > > It says *nothing* about how differentiation is done. That is indeed > > > a separate and quite complex discussion, that will keep the QOS > > > community busy for years. > > > > I believe a bit similar arguments were on the table when mobileip working > > group proposed MIPv6 to the IESG, and it got pushed down, as "doesn't > > work, be more specific". That was some 2-3 years ago, and only now MIPv6 > > is nearing completion. > > > > I'd rather handle these kind of issues before IESG, if possible. > > > > The problems are different, but there seem to be some dangerous common > > elements. > > > > > The idea is to keep that discussion out > > > of the IPv6 WG, by defining the boundary conditions here, so that > > > the flow label becomes a viable tool for differentiation downstream. > > > > My fear is that false assumptions lead to wrong conclusions and broken > > tools, and wasted effort (both from IPv6 wg and especially from the > > follow-up wgs). > > > > > I think this was clear in the previous WG discussions. > > > > Unfortunately, the flood was so huge at a point that I couldn't keep up > > (because I didn't really even care, except whether WG would go on a course > > which seems really problematic, like now) > > > > > > This would be equivalent to replacing network ingress filtering (to drop > > > > packets with forged source addresses) to a requirement for nodes to allow > > > > out only packets which include their own source address. > > > > > > > > > (By the way, do > > > you think nodes *should* be allowed to forge the source address?) > > > > I'll answer this first. > > > > The nodes certainly should be allowed (in the kernel level) to forge the > > source addresses: any model which forces this is broken. > > > > The reason for breakage is that such a model assumes that the nodes behave > > "properly". For most cases, that is correct. But because there is still > > a huge number of systems behaving differently, you cannot depend on it, > > and assuming it is being done would be wrong. > > > > The right (my humble POV, of course :-) answers to your question are: > > > > - no, the user privileged process on a node should not be able to set the > > source address (no problem today) > > - no, the *network* where the node is attached to should not allow the > > user to forge the source address (note: different administrative entity) > > > > > No. The checks can perfectly well be applied at ISP ingress. > > > > Yes, but as the first comment seems to show, in practise this checking > > would be de-facto removed for performance etc. reasons. > > > > > I did want to include more aggressive text about ingress > > > filtering, but in fact it would be out of place. > > > > I'm not sure which kind of text you're referring to, but IMO ingress > > filtering misses the biggest point. > > > > > > Needless to say this seems to indicate a major oversight of the > > > > security/operational reality. I'd be very surprised if this was not > > > > pushed back in the IESG unless this caveat is very explicitly documented. > > > > > > I think your interpretation is quite wrong, but we can certainly ask a > > > security expert or two. > > > > Ok. > > > > To try to clarify what I meant, let me try to explain it again. > > > > Any model that requires that source nodes prevent the root/administrator > > from willingly doing something, and more or less *depending on that* is > > broken. > > > > Let me try to give an example. When Windows XP was being published, some > > very popular magazines were writing about their belief that adding "raw > > sockets" functionality would be catastrophic for the Internet, degrade > > security as people could "now" send any kind of packets they'd want etc. > > The reality was entirely different. Such can be done *anyway*, using > > other implementations, using different mechanisms to achieve the same > > goal, etc. > > > > This is a similar issue. Given an *untrusted* node, specifying mechanisms > > which try to make the *untrusted* node do something you'd like to trust > > (to a rather full extent) seems *completely* bogus.. > > > > Certainly, one should specify checks that user-mode applications MUST NOT > > be able to re-use flow labels within a lifetime, but that's entirely > > different from the approach in the draft. > > > > Certainly, this is a very problematic issue (which was thought to be > > solved later, in some other w.g.). I'm not requiring it be solved here. > > But I'm requiring that we don't pass the problem on without stating *very* > > explicitly the issues why it might/might not work properly -- so that any > > followup efforts that might start to build QoS mechanisms on this would > > not start with an entirely different set of assumptions (easily leading to > > wrong conclusions and broken tools). > > > > I'm not sure if I managed to make the point any clearer, I hope so. > > > > I'd also really appreciate comment on this viewpoint (for or against :-) > > from everybody. > > > > Especially those with (ISP) operator [the "customer of the IETF" in this > > instance] or security background would be encouraged to speak up. :-) > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 03:47:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Blg7f028400; Thu, 6 Mar 2003 03:47:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26BlfW7028399; Thu, 6 Mar 2003 03:47:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Blc7f028392 for ; Thu, 6 Mar 2003 03:47:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26Bljvx001906 for ; Thu, 6 Mar 2003 03:47:46 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29999 for ; Thu, 6 Mar 2003 04:47:39 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:47:38 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:47:38 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:47:38 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:47:38 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5575C6A902; Thu, 6 Mar 2003 13:47:30 +0200 (EET) Message-Id: <3E673523.4010707@kolumbus.fi> Date: Thu, 06 Mar 2003 13:46:43 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com, bzill@microsoft.com, "Steven M. Bellovin" Subject: Re: zill-ipv6wg-zone-prefixlen-00 comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a comment on the Zill draft as well as the Bellovin draft. The Zill draft lacks instructions for the host on what it should *do* with the information it receives. The Bellovin draft, however, describes this in its Section 2.3. I'm fine with that description. However, I worry about one paragraph: In their default configuration, devices MUST NOT accept packets from any non-link-local prefixes until they have received suitable advertisements. However, there MAY be a configuration option to permit acceptance of packets with the current link's prefix. If this text is to be taken literally, it would imply that a host that supports this extension could never communicate outside the link if the router doesn't support the same extension. I'm assuming this only applies *if* the use of the advertisements has been configured on? And then I have some higher-level questions. Steven says himself in the draft that its an open question whether such an extension should exist. I have a few related questions. One question is why this would have to be done by the nodes, wouldn't it be simpler to do this in the routers (acting also as firewalls)? Note that to use the extension, you'd have to configure the routers anyway. In this case the argument about the hardness of filter configuration on a toaster isn't very good. Secondly, I know you Steven have worked on distributed firewalls. Do you think we should have a very simple mechanism for filtering as a part of neighbor discovery, a more powerful but also more complex mechanism running at higher layers, or both? Jari -------------------------------------------------------------------- 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 Mar 6 03:50:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26BoA7f028484; Thu, 6 Mar 2003 03:50:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26Bo9bU028483; Thu, 6 Mar 2003 03:50:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Bo67f028476 for ; Thu, 6 Mar 2003 03:50:06 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26BoEvx002389 for ; Thu, 6 Mar 2003 03:50:14 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10366 for ; Thu, 6 Mar 2003 03:50:07 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:50:06 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:50:06 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:50:06 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 11:49:52 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h26BnfFg095116; Thu, 6 Mar 2003 12:49:43 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h26BmOhS089332; Thu, 6 Mar 2003 12:48:25 +0100 Received: from gsine03.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45686 from ; Thu, 6 Mar 2003 12:48:21 +0100 Message-Id: <3E67353B.D513446A@hursley.ibm.com> Date: Thu, 06 Mar 2003 12:47:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Michel Py Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" References: <963621801C6D3E4A9CF454A1972AE8F5045488@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, can you respond to Pekka's comments? He and I simply don't see things the same, and we need a few more opinions to see where the consensus lies. Brian Michel Py wrote: > > > Brian E Carpenter wrote: > > My concerns were handled in the various rounds between > > the authors (mainly by taking stuff out, which is what > > the WG asked for anyway). > > Ship it. > > Michel. -------------------------------------------------------------------- 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 Mar 6 04:54:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Cs57f029125; Thu, 6 Mar 2003 04:54:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26Cs5k1029124; Thu, 6 Mar 2003 04:54:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Cs27f029117 for ; Thu, 6 Mar 2003 04:54:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26Cs9vx013490 for ; Thu, 6 Mar 2003 04:54:09 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA02580 for ; Thu, 6 Mar 2003 05:54:02 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 12:54:01 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 12:54:01 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 12:54:01 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 12:54:00 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA14315; Thu, 6 Mar 2003 04:53:45 -0800 (PST) Message-Id: <5.1.0.14.2.20030306075052.02d6a998@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Mar 2003 07:52:33 -0500 To: Pekka Savola From: Margaret Wasserman Subject: Re: Draft IPv6 working group charter Cc: Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com In-Reply-To: References: <4.3.2.7.2.20030305143621.02332bc0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > - Complete work on Scoped Addressing Architecture and publish. > >==> this will probably stay in limbo until some closure is reached about >site-local addressing, so putting it in a charter (as it depends on the >site-local course) may be a bit premature -- but ok if not too many cycles >are used for it now. The charter is intended to cover all of the work that we need to do before the WG goes on hiatus. We will need to finish the scoped addressing architecture, but obviously some of this work is dependent on other deliverables (i.e. figuring out what to say about site-locals). Margaret -------------------------------------------------------------------- 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 Mar 6 06:46:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Ekx7f029561; Thu, 6 Mar 2003 06:46:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26Ekxbl029560; Thu, 6 Mar 2003 06:46:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Ekt7f029553 for ; Thu, 6 Mar 2003 06:46:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26El3Yt018454 for ; Thu, 6 Mar 2003 06:47:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03990 for ; Thu, 6 Mar 2003 07:46:57 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 14:46:38 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Thu, 6 Mar 2003 14:44:22 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Thu, 6 Mar 2003 14:46:25 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP; Thu, 6 Mar 2003 14:46:25 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26EkFQ17703; Thu, 6 Mar 2003 16:46:15 +0200 Date: Thu, 6 Mar 2003 16:46:14 +0200 (EET) From: Pekka Savola To: Bill Manning cc: Alain Durand , , Subject: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] In-Reply-To: <200303051817.h25IHcY20379@boreas.isi.edu> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Mar 2003, Bill Manning wrote: > As a co-author of a couple of previous DNS discovery IDs, I would > have to agree that as postulated, the current DNS discovery work > has pretty much been OBE. (overtaken by events) > There have been two distinct BOFs on this idea in the last five years > so I don't think another BOF will be very productive. I assume those BOFs were for IPv4? When considering DNS discovery in IPv6 context, we need to consider the scope of such discovery -- ie. where it is expected to be used, and possible subsequent configuration methods. As I see it, DNS discovery can either be: 1) "all that you need" 2) "the first step" In the first model, you need no other information. When you've completed DNS discovery, that's it. This is a very valid scenario in e.g. mobile environments, when visiting networks (for example, at IETF's, I run dhcpv4 *only* to get the DNS address :-( ). In the second model, you generally want to obtain also other information. This typically applies to non-visiting networks, like an enterprise LAN. The question becomes which tool is used (or fits best) in getting that information. If you need/want to use DHCPv6 (stateful or stateless) for that, no use having a separate mechanism for DNS and the rest. The critical thing in the 2nd model is whether DNS resolvers enable some config mechanisms: they certainly enable being able to surf to the home page of your own (or enterprise) from where you can obtain some values, scripts which give you the configuration you want etc. But perhaps more importantly, you could place configuration details in the DNS, in some format. So, basically if one believes roaming users or DNS-based configuration would be nice, some easy DNS resolver configuration mechanism would be "very nice". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 07:12:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26FCG7f029912; Thu, 6 Mar 2003 07:12:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26FCG8A029911; Thu, 6 Mar 2003 07:12:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26FCC7f029904 for ; Thu, 6 Mar 2003 07:12:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26FCKYt023776 for ; Thu, 6 Mar 2003 07:12:20 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07883 for ; Thu, 6 Mar 2003 08:12:14 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:12:13 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:12:12 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:12:11 Z Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:12:11 Z Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id h26FBaM00904; Thu, 6 Mar 2003 07:11:36 -0800 (PST) From: Bill Manning Message-Id: <200303061511.h26FBaM00904@boreas.isi.edu> Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] In-Reply-To: from Pekka Savola at "Mar 6, 3 04:46:14 pm" To: pekkas@netcore.fi (Pekka Savola) Date: Thu, 6 Mar 2003 07:11:36 -0800 (PST) Cc: bmanning@ISI.EDU, Alain.Durand@Sun.COM, narten@us.ibm.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % On Wed, 5 Mar 2003, Bill Manning wrote: % > As a co-author of a couple of previous DNS discovery IDs, I would % > have to agree that as postulated, the current DNS discovery work % > has pretty much been OBE. (overtaken by events) % > There have been two distinct BOFs on this idea in the last five years % > so I don't think another BOF will be very productive. % % I assume those BOFs were for IPv4? No, they were for DNS discovery. Protocol agnostic. % As I see it, DNS discovery can either be: % % 1) "all that you need" % 2) "the first step" Both points were covered each time. And each time, the result was that DNS discovery should be limited to point #1. Point #2 is covered under the DHCP work and should not be replicated. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). -------------------------------------------------------------------- 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 Mar 6 07:17:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26FHe7f000087; Thu, 6 Mar 2003 07:17:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26FHe7w000086; Thu, 6 Mar 2003 07:17:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26FHb7f000079 for ; Thu, 6 Mar 2003 07:17:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26FHiYt025126 for ; Thu, 6 Mar 2003 07:17:44 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22258 for ; Thu, 6 Mar 2003 08:17:38 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:17:38 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Thu, 6 Mar 2003 15:15:35 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Thu, 6 Mar 2003 15:17:37 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP; Thu, 6 Mar 2003 15:17:36 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h26FHRI17906; Thu, 6 Mar 2003 17:17:27 +0200 Date: Thu, 6 Mar 2003 17:17:26 +0200 (EET) From: Pekka Savola To: Bill Manning cc: Alain.Durand@Sun.COM, , Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] In-Reply-To: <200303061511.h26FBaM00904@boreas.isi.edu> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 6 Mar 2003, Bill Manning wrote: > % On Wed, 5 Mar 2003, Bill Manning wrote: > % > As a co-author of a couple of previous DNS discovery IDs, I would > % > have to agree that as postulated, the current DNS discovery work > % > has pretty much been OBE. (overtaken by events) > % > There have been two distinct BOFs on this idea in the last five years > % > so I don't think another BOF will be very productive. > % > % I assume those BOFs were for IPv4? > > No, they were for DNS discovery. Protocol agnostic. That avoids the question (which I hoped was clear, but perhaps not). If you have to run DHCPv4 in any case to get an IPv4 address to be able to use the net, I'm certain nothing could come of such a BOF. > > % As I see it, DNS discovery can either be: > % > % 1) "all that you need" > % 2) "the first step" > > Both points were covered each time. And each time, the result > was that DNS discovery should be limited to point #1. Good. > Point #2 is covered under the DHCP work and should not > be replicated. Ok, but one argument is that DHCP is too address-assignment -specific. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 07:33:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26FX27f000551; Thu, 6 Mar 2003 07:33:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26FX2tx000550; Thu, 6 Mar 2003 07:33:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26FWx7f000543 for ; Thu, 6 Mar 2003 07:32:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26FX6Yt029090 for ; Thu, 6 Mar 2003 07:33:06 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20807 for ; Thu, 6 Mar 2003 08:33:00 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:33:00 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:32:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:32:59 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 15:32:58 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h26FWfEI076466; Thu, 6 Mar 2003 16:32:45 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.5) with SMTP id h26FWYhS111868; Thu, 6 Mar 2003 16:32:34 +0100 Received: from gsine02.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56442 from ; Thu, 6 Mar 2003 16:32:30 +0100 Message-Id: <3E673FC8.ADC197AA@hursley.ibm.com> Date: Thu, 06 Mar 2003 13:32:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: trusting end-nodes to do the right thing [Re: IPv6 w.g. LastCallon "IPv6 Flow Label Specification"] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Please send text for what you think we should add to the security considerations. Personally, I see no reason why the ISP's trust model changes here. Most IP header fields potentially used for QOS classification are forgeable. This isn't a flow label problem, or an IPv6 problem, or even an IP problem. It's a characteristic of connectionless datagrams. All your other points really are not new issues, and we have been working on the draft for more than a year to make it fit around the various perspectives expressed in the WG. Brian Pekka Savola wrote: > > On Thu, 6 Mar 2003, Brian E Carpenter wrote: > > Pekka Savola wrote: > > > > > > We may be treading into a very difficult situation (in some ways similar > > > to why MIPv6 got pushback from the IESG, IMO), and to be pre-emptive, I'd > > > really appreciate if folks would have a look at the particular issue (at > > > the end of the mail) and think whether it is a problem or not. > > > > The flow label has been a forgeable field since IPSEC decided to leave > > it outside the crypto calculation. I'd be very happy if this decision > > could be reversed, since the field is immutable, but I don't think that > > is realistic. IMHO the IESG would have no grounds for raising this now; > > it derives automatically from ancient decsions. > > The use of IPsec seems irrelevant for the *ISP* as they can't verify it > -- no help there. > > The problem is of trying to make untrusted end-nodes trusted to label the > flows properly. Changing IPsec will not help (except if you assume > communication is to e.g. ISP's own servers, middleboxes etc.). > > > I agree that we should get a security person to look at your comments, but > > unless anyone else supports your concern, it's my impression that you are > > worrying about something we cannot change anyway. > > There are two most major issues here: > > 1) something we should change > 2) something we must document if we cannot change > > I'm requiring at least 2). > > > The security considerations > > simply document facts of life. > > Unfortunately, the security considerations as of now *does not* document > these facts of life. This is the biggest concern. > > Of course, I strongly also want to change the model slightly (e.g. the > MUST requirement for nodes not to send out used flow lables), to make it > the restrictions of the model clearer. This does not yet fix the core > problem, how the ISP can make anything of these labels -- trust them -- > but at least now the starting assumptions are closer to correct. > > The extreme case would be taking a full halt here for all of the flow > label draft, working out the details, and only then publishing it. I > don't think this is correct approach for now. > > > > On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > > > > The 3-tuple of the Flow Label and the Source and Destination Address > > > > > fields enables efficient IPv6 flow classification, where only IPv6 > > > > > main header fields in fixed positions are used. > > > > > > > > > > ==> this might require some extra analysis somewhere (not in that > > > > > particular place, I think). In particular, this seems to say that once > > > > > this is published people can happily move to using the three-tuple > > > > > classification. The reality is probably quite different, and one must > > > > > also consider the big portion of nodes which do not mark the flows. > > > > > > > > The goal of this document is not to describe use cases. It is > > > > to set the minimum conditions hosts and routers must meet. I do > > > > not believe we should add use cases to this document. > > > > > > I believe the original text does not give a realistic picture of the > > > situation. > > > > > > For the purpose of minimum conditions, the text could be removed > > > altogether, of course -- that would be fine by me. I could also live with > > > (by a thread :-) the current version, but I really believe it should be > > > changed slightly. > > > > > > > > To enable applications and transport protocols to define what packets > > > > > constitute a flow, the source node MUST provide means for the > > > > > applications and transport protocols to specify the Flow Label values > > > > > to be used with their flows. > > > > > > > > > > ==> this requirement seems unacceptable at the moment. This clearly > > > > > requires (at least) de-facto API so applications could set Flow Label > > > > > values -- and as such does not exist. If it did (and I believe there's > > > > > work in progress), there would *have to be* a normative reference to it). > > > > > So, clearly a MUST seems to a big no-no. > > > > > > > > But this is a statement about what hosts must do to make the flow label > > > > useful. > > > > > > No, that's not correct, or either of us is misunderstanding the paragraph > > > above (if so, a wording change is needed). > > > > > > The nodes (kernel, in particular) are able to mark flows by itself, > > > without any interaction from the applications -- so having apps have a > > > MUST possibility to influence the flow labeling is undoubtedly useful, but > > > certainly not something requiring MUST, considering the current situation. > > > > > > Note: I'd argue for MUST myuself if we had had a standard (or even > > > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > > > year before this being sent to the IESG. > > > > > > > If you want to standardize a socket API extension that's fine, > > > > the Open Group exists for that. However, I believe a MUST is needed. > > > > > > A MUST without a means is bad practise, IMO. > > > > > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > > > is currently using or has recently used when creating new flows. Flow > > > > > Label values previously used with a specific pair of source and > > > > > destination addresses MUST NOT be assigned to new flows with the same > > > > > address pair within 120 seconds of the termination of the previous > > > > > flow. > > > > > > > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > > > > value which was previously used, and send the packet, the operating system > > > > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > > > > s/reuse/unintentionally reuse/, or some other rewording? > > > > > > > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > > > > we included an algorithm, but the WG wanted it removed, so we removed it. > > > > > > Yes, the stack can do it easily -- no doubt about that -- but it's > > > *wrong*; this is connected to the security issue, below. > > > > > > > > To enable co-existence of different methods in IPv6 nodes, the > > > > > methods MUST meet the following basic requirements: > > > > > > > > > > ==> this and the following points seem a little oddly placed in this memo: > > > > > they seem out-of-place, as the rest of the memo seems to concentrate on > > > > > entirely different issues. Personally I view specifying how source nodes > > > > > should label flows one thing, and the rest entirely another. But I can > > > > > live with these, even though I think they're more fit to a non-standards > > > > > track document. > > > > > > > > Then you don't want a change here? > > > > > > I can live without it -- waiting to hear others' opinions -- but I think > > > the source node behaviour is entirely different issue from the network > > > treatment. > > > > > > > > 5.1 Theft and Denial of Service > > > > > > > > > > ==> this section mainly deals with issues relating to forging all of the > > > > > source,destination,label three-tuple (exception is the last paragraph, > > > > > which deals with a trusted-node-but-untrusted-user/application case), > > > > > which protects mainly against a DoS attack (resource depletion). > > > > > > > > > > This seems to overlook the most important part: the typical model today is > > > > > that operators perform differentiation of flows *themselves*: this > > > > > document proposes to shift that, *over an administrative boundary*, to the > > > > > source nodes, which suddenly become trusted to do the right thing. > > > > > > > > No, it adds the *labelling* of flows to the source, as a new capability. > > > > > > The labeling with current "service model" leads to differentiation. I'll > > > try to reword it again below. If the "service model" would be such that > > > the source node is *not* expected to label flows correctly, I'd certainly > > > agree. > > > > > > > It says *nothing* about how differentiation is done. That is indeed > > > > a separate and quite complex discussion, that will keep the QOS > > > > community busy for years. > > > > > > I believe a bit similar arguments were on the table when mobileip working > > > group proposed MIPv6 to the IESG, and it got pushed down, as "doesn't > > > work, be more specific". That was some 2-3 years ago, and only now MIPv6 > > > is nearing completion. > > > > > > I'd rather handle these kind of issues before IESG, if possible. > > > > > > The problems are different, but there seem to be some dangerous common > > > elements. > > > > > > > The idea is to keep that discussion out > > > > of the IPv6 WG, by defining the boundary conditions here, so that > > > > the flow label becomes a viable tool for differentiation downstream. > > > > > > My fear is that false assumptions lead to wrong conclusions and broken > > > tools, and wasted effort (both from IPv6 wg and especially from the > > > follow-up wgs). > > > > > > > I think this was clear in the previous WG discussions. > > > > > > Unfortunately, the flood was so huge at a point that I couldn't keep up > > > (because I didn't really even care, except whether WG would go on a course > > > which seems really problematic, like now) > > > > > > > > This would be equivalent to replacing network ingress filtering (to drop > > > > > packets with forged source addresses) to a requirement for nodes to allow > > > > > out only packets which include their own source address. > > > > > > > > > > > > (By the way, do > > > > you think nodes *should* be allowed to forge the source address?) > > > > > > I'll answer this first. > > > > > > The nodes certainly should be allowed (in the kernel level) to forge the > > > source addresses: any model which forces this is broken. > > > > > > The reason for breakage is that such a model assumes that the nodes behave > > > "properly". For most cases, that is correct. But because there is still > > > a huge number of systems behaving differently, you cannot depend on it, > > > and assuming it is being done would be wrong. > > > > > > The right (my humble POV, of course :-) answers to your question are: > > > > > > - no, the user privileged process on a node should not be able to set the > > > source address (no problem today) > > > - no, the *network* where the node is attached to should not allow the > > > user to forge the source address (note: different administrative entity) > > > > > > > No. The checks can perfectly well be applied at ISP ingress. > > > > > > Yes, but as the first comment seems to show, in practise this checking > > > would be de-facto removed for performance etc. reasons. > > > > > > > I did want to include more aggressive text about ingress > > > > filtering, but in fact it would be out of place. > > > > > > I'm not sure which kind of text you're referring to, but IMO ingress > > > filtering misses the biggest point. > > > > > > > > Needless to say this seems to indicate a major oversight of the > > > > > security/operational reality. I'd be very surprised if this was not > > > > > pushed back in the IESG unless this caveat is very explicitly documented. > > > > > > > > I think your interpretation is quite wrong, but we can certainly ask a > > > > security expert or two. > > > > > > Ok. > > > > > > To try to clarify what I meant, let me try to explain it again. > > > > > > Any model that requires that source nodes prevent the root/administrator > > > from willingly doing something, and more or less *depending on that* is > > > broken. > > > > > > Let me try to give an example. When Windows XP was being published, some > > > very popular magazines were writing about their belief that adding "raw > > > sockets" functionality would be catastrophic for the Internet, degrade > > > security as people could "now" send any kind of packets they'd want etc. > > > The reality was entirely different. Such can be done *anyway*, using > > > other implementations, using different mechanisms to achieve the same > > > goal, etc. > > > > > > This is a similar issue. Given an *untrusted* node, specifying mechanisms > > > which try to make the *untrusted* node do something you'd like to trust > > > (to a rather full extent) seems *completely* bogus.. > > > > > > Certainly, one should specify checks that user-mode applications MUST NOT > > > be able to re-use flow labels within a lifetime, but that's entirely > > > different from the approach in the draft. > > > > > > Certainly, this is a very problematic issue (which was thought to be > > > solved later, in some other w.g.). I'm not requiring it be solved here. > > > But I'm requiring that we don't pass the problem on without stating *very* > > > explicitly the issues why it might/might not work properly -- so that any > > > followup efforts that might start to build QoS mechanisms on this would > > > not start with an entirely different set of assumptions (easily leading to > > > wrong conclusions and broken tools). > > > > > > I'm not sure if I managed to make the point any clearer, I hope so. > > > > > > I'd also really appreciate comment on this viewpoint (for or against :-) > > > from everybody. > > > > > > Especially those with (ISP) operator [the "customer of the IETF" in this > > > instance] or security background would be encouraged to speak up. :-) > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 6 11:31:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26JVn7f002968; Thu, 6 Mar 2003 11:31:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26JVnDC002967; Thu, 6 Mar 2003 11:31:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26JVk7f002960 for ; Thu, 6 Mar 2003 11:31:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26JVrvx003190 for ; Thu, 6 Mar 2003 11:31:53 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02847 for ; Thu, 6 Mar 2003 11:31:47 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:31:47 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:31:46 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:31:46 Z Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:31:46 Z Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h26JVXVA028185; Thu, 6 Mar 2003 11:31:33 -0800 (PST) Received: from SIVAV.qualcomm.com (sivav.qualcomm.com [129.46.222.34]) by magus.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h26JVVuw023685; Thu, 6 Mar 2003 11:31:31 -0800 (PST) Message-Id: <4.3.2.7.2.20030306112716.050d73c8@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Mar 2003 11:31:30 -0800 To: "Digambar Rasal" From: Siva Veerepalli Subject: Re: Web Server addresses : Unicast , Multicast , Anycast Cc: In-Reply-To: <001601c2c0fd$ec943530$e20aa8c0@digambar> References: <001301c2bc48$737cef70$e20aa8c0@digambar> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:03 AM 1/21/2003 +0530, Digambar Rasal wrote: >Hi > >I am developing a Web server , router , load balancers, Gateway and Switch >testing software. > >I have read the RFC reagrding the addressing in IPv6 and I understood that >Web servers , routers , load balancers, Gateways and Switches can have >either Unicast or Multicast or Anycast address. I think there is a restriction on the use of anycast addresses. As I understand it, use of anycast is allowed for routers only at the current time (see http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt). Siva >I am not sure that my interpretation is correct .. So please correct if I >am wrong. > >Regards >Digambar Rasal > > >-------------------------------------------------------------------- >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 Thu Mar 6 11:42:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Jg07f003306; Thu, 6 Mar 2003 11:42:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h26Jfxnb003305; Thu, 6 Mar 2003 11:41:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h26Jft7f003295 for ; Thu, 6 Mar 2003 11:41:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h26Jg3Yt019504 for ; Thu, 6 Mar 2003 11:42:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09861 for ; Thu, 6 Mar 2003 11:41:57 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:41:56 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:39:52 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:41:56 Z Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 6 Mar 2003 19:41:55 Z Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.8/8.12.8) with ESMTP id h26JfrkH005474; Thu, 6 Mar 2003 14:41:53 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.8/8.12.8) with ESMTP id h26Jflwi056060; Thu, 6 Mar 2003 14:41:47 -0500 (EST) Received: from cupid (cupid [135.180.144.140]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with SMTP id OAA15455; Thu, 6 Mar 2003 14:41:47 -0500 (EST) From: "Daniel G Waddington" To: , Subject: IEEE Communications Magazine Feature Topic on IPv6 - CFP Date: Thu, 6 Mar 2003 14:39:25 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ** CALL FOR PAPERS ** IEEE Communications Magazine "IPv6 - The basis for the next generation Internet" Background ---------- The next version of the Internet Protocol called IPv6 has evolved considerably since it as first defined in the early 90's. Whereas the main thrust of IPv6 is the greatly increased addressing space, which is expected to provide ample address space for the foreseeable future, IPv6 also introduces several other features like integrated security (IPsec), ntegrated multicasting, improved mobility support (Mobile IPv6), QoS support with the provisioning of flow labels and autoconfiguration. Router products supporting dual stack operation with IPv4 and IPv6 have entered the market during the last two years. Nevertheless the adoption of IPv6 is progressing rather slowly. This is mainly due to the fact that the introduction of a new network layer is a difficult and expensive step for network operators and ISPs and a strong demand for IPv6 from the user perspective is still lacking. However, the shortage of addresses particularly in Asia and Europe and the trend to mobile and ubiqitous networking makes the introduction of IPv6 an urgent issue. Scope of Expected Contributions ------------------------------- We invite contributions covering all aspects of next generation, IPv6-based networks, including, but not limited to routing and address space management, security and privacy aspects, multicasting and multimedia distribution networks, mobile network architecture, impact on other protocol layers and services, as well as performance aspects in IPv6. In addition we invite contributions on IPv4 to IPv6 transition and introduction strategies, large scale IPv6 trial experiences and commercial service introduction, user requirements, as well as ubiquitous networking applications and IPv6 management and operations support. Preference will be given to contributions covering specific advantages or problems in large scale IPv6 networks, rather than to introductory IPv6 papers. Schedule and Submissions ------------------------ · Submission Deadline: May 15, 2003 · Acceptance Notifications: August 15, 2003 · Final Manuscript Due: October 15, 2003 · Journal Publication: January 2004 · All contributions must be sent by email as .PDF or .PS files to all three editors Feature Topic Editors --------------------- Heinrich J. Stüttgen NEC Networking Laboratories Kurfürstenanlage 36, D 69115 Heidelberg, Germany Email: stuttgen@ccrle.nec.de Tel: +49 6221 90511 11 Fax: +49 6221 90511 55 Han-Chieh Chao Department of Electrical Engineering National Dong Hwa University Hualien, Taiwan E-mail: hcc@mail.ndhu.edu.tw Tel: +886 3 8662500 ext.17001 Fax: +886 3 8662509 Daniel G. Waddington Bell Labs, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733, USA E-mail: dwaddington@lucent.com Tel: +1 732 949 3959 -------------------------------------------------------------------- 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 Mar 6 16:10:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h270An7f004919; Thu, 6 Mar 2003 16:10:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h270Ane9004918; Thu, 6 Mar 2003 16:10:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h270Aj7f004911 for ; Thu, 6 Mar 2003 16:10:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h270Aqvx008318 for ; Thu, 6 Mar 2003 16:10:52 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18922 for ; Thu, 6 Mar 2003 17:10:46 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:10:44 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:10:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:10:44 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:10:43 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20326; Thu, 6 Mar 2003 19:08:24 -0500 (EST) Message-Id: <200303070008.TAA20326@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: IP Version 6 Addressing Architecture to Proposed Standard Date: Thu, 06 Mar 2003 19:08:24 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IP Version 6 Addressing Architecture' as a Proposed Standard. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary This specification defines the addressing architecture of the IP Version 6 protocol (RFC 2460). 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. Working Group Summary This document was approved by the IESG as a Draft Standard in October, 2002. Subsequently, an appeal was filed regarding the IESG decision, and the IAB issued a response in which it annulled the IESG approval for Draft Standard. The IAB response included the following: We recommend to the IESG that the current version of the I-D draft be published as a Proposed Standard. That is what this protocol action does. The working group supported the recomendation to publish the current document as a Proposed Standard. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- 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 Mar 6 16:21:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h270L97f005137; Thu, 6 Mar 2003 16:21:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h270L8gr005136; Thu, 6 Mar 2003 16:21:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h270L47f005129 for ; Thu, 6 Mar 2003 16:21:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h270LCvx011403 for ; Thu, 6 Mar 2003 16:21:12 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03924 for ; Thu, 6 Mar 2003 17:21:06 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:18:53 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:18:52 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:18:52 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 00:18:52 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20583; Thu, 6 Mar 2003 19:16:45 -0500 (EST) Message-Id: <200303070016.TAA20583@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block to Informational Date: Thu, 06 Mar 2003 19:16:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block' as an Informational RFC. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. -------------------------------------------------------------------- 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 Mar 7 03:55:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h27BtS7f006946; Fri, 7 Mar 2003 03:55:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h27BtSFh006945; Fri, 7 Mar 2003 03:55:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h27BtM7f006931 for ; Fri, 7 Mar 2003 03:55:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h27BtVvx004278 for ; Fri, 7 Mar 2003 03:55:31 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08824 for ; Fri, 7 Mar 2003 04:55:25 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 11:55:25 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 11:53:19 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 11:55:25 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 11:55:24 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21272; Fri, 7 Mar 2003 06:53:19 -0500 (EST) Message-Id: <200303071153.GAA21272@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-09.txt Date: Fri, 07 Mar 2003 06:53: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 IP Version 6 Working Group Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-09.txt Pages : 79 Date : 2003-3-6 A separate specification [BASICAPI] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications. This document defines some of the 'advanced' features of the sockets API that are required for applications to take advantage of additional features of IPv6. Today, the portability of applications using IPv4 raw sockets is quite high, but this is mainly because most IPv4 implementations started from a common base (the Berkeley source code) or at least started with the Berkeley header files. This allows programs such as Ping and Traceroute, for example, to compile with minimal effort on many hosts that support the sockets API. With IPv6, however, there is no common source code base that implementors are starting from, and the possibility for divergence at this level between different implementations is high. To avoid a complete lack of portability amongst applications that use raw IPv6 sockets, some standardization is necessary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-rfc2292bis-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-09.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6125231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125231.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 Mar 7 12:36:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h27Kao7f008965; Fri, 7 Mar 2003 12:36:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h27Kao4Z008964; Fri, 7 Mar 2003 12:36:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h27Kak7f008957 for ; Fri, 7 Mar 2003 12:36:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h27KatYt005122 for ; Fri, 7 Mar 2003 12:36:55 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00054 for ; Fri, 7 Mar 2003 13:36:49 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 20:36:49 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 20:34:42 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 20:36:48 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 20:36:48 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29158; Fri, 7 Mar 2003 15:34:41 -0500 (EST) Message-Id: <200303072034.PAA29158@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-node-requirements-03.txt Date: Fri, 07 Mar 2003 15:34:41 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Node Requirements Author(s) : J. Loughney Filename : draft-ietf-ipv6-node-requirements-03.txt Pages : 21 Date : 2003-3-7 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ipv6-node-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-node-requirements-03.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7150531.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-node-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-node-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7150531.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 Mar 7 13:01:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h27L1S7f009748; Fri, 7 Mar 2003 13:01:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h27L1R2a009747; Fri, 7 Mar 2003 13:01:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h27L1O7f009740 for ; Fri, 7 Mar 2003 13:01:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h27L1XYt015427 for ; Fri, 7 Mar 2003 13:01:33 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13558 for ; Fri, 7 Mar 2003 14:01:27 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 21:01:27 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 21:01:26 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 21:01:26 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 7 Mar 2003 21:01:26 Z Content-class: urn:content-classes:message Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 7 Mar 2003 13:01:22 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54C79@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Thread-Index: AcLj1nyQGSmZUyP5Sm25iE0ZJ6aGxwBDLHpQ From: "Michel Py" To: "Brian Carpenter" , "Pekka Savola" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h27L1O7f009741 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian E Carpenter wrote: > Michel, can you respond to Pekka's comments? He and > I simply don't see things the same, and we need a few > more opinions to see where the consensus lies. Two sides, one technical for some aspects and one more general. Disclaimer: I do not consider myself a flow label specialist. Technical: A lot is not directly related to Pekka's comments, my goal here is to explain the reasons that lead me to my current positions. > the source node MUST provide means for the applications and > transport protocols to specify the Flow Label values to be > used with their flows. This makes sense to me. I do not feel the urge for the "API" nor for case uses at this time. > Packet classifiers use the triplet of Flow Label, > Source Address, and Destination Address fields When we discussed the interaction between MHAP and flow label in Atlanta, this (vs. a random number) appeared to be the way to go. The main concern I had at the time was that the source and destination address needed to remain in the classifier. Although this is somehow a guess derived from the limited set we have to look at today, I do think that this type of classifier is a fundamental requirement for dual-space systems, and dual-space system are currently percept to be the way out that would provide PI-like advantages _and_ scalability. In the case of MHAP, since the identifier space and the locator space belong to the same name space which is the IPv6 Global Unicast address space, the choice of which space (the locator or the identifier) is going to be used for the classifier is a no-brainer as both could be, depending if classification takes place before or after aliasing. In other (future) dual-space systems, it might happen that the identifier space is un-classifiable, and there I have a gut feeling that building the classifier with the locator space will be a requirement. About the 3-tuple vs. 5-tuple issue, I do prefer the 3-tuple way, for the reasons mentioned in the text. > The nodes certainly should be allowed (in the kernel level) to > forge the source addresses: any model which forces this is broken. I'm not hot at all about this in the context of a dual-space system. General: There are lots of things in this text that are speculations. In this kind of situation, I tend to favor pushing out text even if nobody really knows. There's only one way to find out, and that way is to try. In terms of consensus, it is my reading of the ML that except Pekka's concerns there is consensus over this text. Is this the right way? Maybe, maybe not, all we have is opinions. The way I approach this is that as long as it does not break what I want to do and I don't hear any screams from other people that it breaks what they want to do (with specifics) and when we have author consensus on the text it's time to ship. Michel. -------------------------------------------------------------------- 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 Mar 7 21:29:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h285TE7f012126; Fri, 7 Mar 2003 21:29:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h285TE6R012125; Fri, 7 Mar 2003 21:29:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h285TA7f012118 for ; Fri, 7 Mar 2003 21:29:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h285TJYt016461 for ; Fri, 7 Mar 2003 21:29:19 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA00228 for ; Fri, 7 Mar 2003 21:29:13 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:29:13 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:29:13 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:29:13 Z Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:29:11 Z Disposition-notification-to: soohong.park@samsung.com Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBF00C050IZVV@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 08 Mar 2003 14:28:11 +0900 (KST) Received: from ep_mmp1 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBF00C0P0IYV6@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 08 Mar 2003 14:28:10 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBF00IGN11GAC@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 08 Mar 2003 14:39:17 +0900 (KST) Date: Sat, 08 Mar 2003 14:27:50 +0900 From: Soohong Daniel Park Subject: [Draft] The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header To: ipng@sunroof.eng.sun.com Message-Id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/mixed; boundary="Boundary_(ID_tDlCzlI4o13z0VWY8crRNw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_tDlCzlI4o13z0VWY8crRNw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear folks. I'd like to discuss this draft "The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header", it's not submitted yet. Before I propose, I want to listen some comments and opinion from IPv6 folks. I'll attack this draft. Please look into and response. Daniel ------------------------------------------------------------------------ --------------------------------------------------- Abstract This document presents a new method for the PMTU discovery for IPv6. To discover the PMTU of a path, a source node measures its actual PMTU using the newly defined Hop-by-Hop Option header, whereas a source node initially assumes that the PMTU of a path is the known MTU of the first hop in the path in the previous one [1981]. In order to measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet when node is beginning. This can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size). Most of all, since existing PMTU has a weak point for security and denial-of-service attacks, this document suggests a security function when PMTU is going on. All IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification. ============================================== Soohong Daniel Park Researcher Mobile Platform Lab, Samsung electronics TEL:+82-31-200-3728 FAX:+82-31-200-3147 mailto:Soohong.Park@samsung.com --Boundary_(ID_tDlCzlI4o13z0VWY8crRNw) Content-type: text/plain; name=draft-park-pmtu-ipv6-option-header-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-park-pmtu-ipv6-option-header-00.txt INTERNET-DRAFT Soohong Daniel Park Expires: September 2003 Hakgoo Lee SAMSUNG Electronics March 2003 The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents a new method for the PMTU discovery for IPv6. To discover the PMTU of a path, a source node measures its actual PMTU using the newly defined Hop-by-Hop Option header, whereas a source node initially assumes that the PMTU of a path is the known MTU of the first hop in the path in the previous one [1981]. In order to measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet when node is beginning. This can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size). Most of all, since existing PMTU has a weak point for security and denial-of-service attacks, this document suggests a security function when PMTU is going on. All IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification. Park,Lee Expires September 2003 [Page 1] INTERNET-DRAFT March 2003 Table of Contents Abstract 1. Introduction 2. Terminology 3. Proposed Method : Overview 3.1 Request MAP Option Format 3.2 Response MAP Option Format 4. Node Requirements for Discoverying PMTU 4.1 Source Node and Destination Node 4.2 Nodes on Routing Path 4.3 Operation Procedure 5. Mode Requirements for Detecting PMTU 5.1 Source Node and Destination Node 5.2 Nodes on Routing Path 5.3 Operation Procedure 6. Comparison with [1981] 7. Security Considerations 8. Normative Reference 9. Informative References 10. Acknowledgements 11. Authors' Addresses 12. Intellectual Property 13. Copyright 1. Introduction The discovery of the Path MTU (PMTU) is described in [1981]. The basic idea of [1981] is that a source node initially assumes that the a path's PMTU is the known MTU of the first hop in the path. If any of the packets sent on that path are too large to be forwarded by some node along the path, that node will discard them and return ICMPv6 Packet Too Big messages [2463]. Upon receipt of such a message, the source node reduces its assumed PMTU for the path based on the MTU of the constricting hop as reported in the Packet Too Big message. The PMTU Discovery process ends when packets arrive at the destination node. However, in [1981], there may be several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size), before the actual PMTU is obtained. In the worst case, the number of interactions becomes the number of hops in the path. This method might be somewhat inefficient. Therefore, a new method for the PMTU discovery is suggested in this document. In this new method, to discover the PMTU of a path, the source node measures its actual PMTU using the newly defined Hop-by-Hop Option header. To measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet which should be the its link MTU when node is beginning. After then, the measured PMTU is used to send the subsequent packets. Park,Lee Expires September 2003 [Page 2] INTERNET-DRAFT March 2003 Now, another problem can be considered in PMTU Discovery [1981]. Due to changes in the routing topology, the PMTU of a path may change over time. In [1981], to detect increases of the PMTU of a path, the source node periodically increases its assumed PMTU although this is done infrequently (10 minutes in general). However, in this method, the assumed PMTU is increased by the source node's link MTU unconditionally. This may also result in several iterations of the discovery cycle. This problem can be also resolved by the proposed method. Therefore, in both discovering PMTU and detecting PMTU's increases, the proposed method can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle. Thus, the proposed method in this document can be helpful for the best-conditioned network environment because the actual PMTU is measured dynamically for changes in the routing topology. Finally, existing PMTU [1981] mechanism makes possible some denial-of- service attacks, most of all, both are based on a malicious party sending false Packet Too Big messages to a victim. Accordingly both weak points, it will result in suboptimal performance and availability of denial-of-service attacks. This document suggests the secure PMTU method. It is described in section 7. 2. Terminology o PMTU is the minimum link MTU of all the links in a path between a source node and a destination node. o MTU is stands for Maximum Transmission Unit. i.e., maximum packet size in octets, that can be conveyed in one piece over a link. o Detection Timer Nodes may send PMTU packet at infrequent intervals in order to detect an increase. The recommended setting for this timer is same value as [1981]. (10 minutes) o Response Timer If the source node does not receive the packet with Response MAP Option until the Response Timer expires, the source node initially assumes that the PMTU of a path is the MTU of the first hop in the path as [1981]. o MAP is stands for Measuring Actual PMTU. In order to perform MAP, newly MAP Option must be done. o Discoverying PMTU When node is beginning, node should perform PMTU to discovery its own value. Park,Lee Expires September 2003 [Page 3] INTERNET-DRAFT March 2003 o Detecting PMTU's Increase Nodes may detect increases in PMTU. o Request MAP Option is used to request MAP information to destination. See section 3.1 o Response MAP Option is used to response MAP information to source. See section 3.2 3. Proposed Method : Overview This section gives a brief overview of the new method for the discoverying and detecting PMTU mechanisms. A router on routing path examines only IP header, Hop-by-Hop Option header and routing header in extension header. Other extension headers and data are examined only by a source node and destination node. In the new method, Hop-by-Hop Option header is used to measure increases in a path's PMTU The Hop-by-Hop Option header and Option is defined as below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Currently, Hop-by-Hop Option headers are Pad1, PadN, Jumbo Payload, and Router Alert Options. This document defines a new Option. It is called 'Measuring Actual PMTU (MAP Option)'. Then, the IP packet including Hop-by-Hop Option header with MAP Option has the following format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + Park,Lee Expires September 2003 [Page 4] INTERNET-DRAFT March 2003 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | 0 | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Data(PMTU) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit identifier of the type of Option. Opt Data Len 8-bit unsigned integer. Length of the Option Data field of this Option, in octets. Option Data(PMTU) Measured PMTU value with 4 bytes
The Option Type identifiers are internally encoded such that their highest-order two bits specify the action that must be taken when the router does not recognize the Option Type. The third highest order bit of the Option Type specifies whether or not the Option Data (PMTU) of that Option can change en-route to the packet's final destination. The other five bits are defined arbitrarily. The MAP Option has two Option Types. The one is Request MAP Option and the other is Response MAP Option, which will be shown in following subsections. If any of the routers en-route cannot recognize the Option Types, it skips over or discards the packet silently. It depends on operator policy. o The highest-order two bits of the Option type is 00 If routers are not understand MAP Options, this packet must be skipped over this Option and continue processing the header. When this Option meets with possible router, this PMTU must be modified. When source node receives this response, it is not actual PMTU because all routers are not understand. If received MTU is larger than its own value, this MTU should be ignored. Note : In initiation case, node must use "00" value because of response error message (Packet Too Big message). o The highest-order two bits of the Option type is 01 If routers are not understand MAP Options, this packet must be discarded, at this case, source node has its waiting time. When this time is expired without any response, this node should perform original PMTU as [1981]. Park,Lee Expires September 2003 [Page 5] INTERNET-DRAFT March 2003 This document suggests that if specific link should be performed with small PMTU value, at this point, MAP Options should be applied. 3.1 Request MAP Option Format The Request MAP Option format is defined to measure real PMTU as shown in Figure 3. The source node sends the IP packet with this Request MAP Option format to the destination node. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 x 1|1 0 0 0 0|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P M T U | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Highest-order two bits 00 - Skip over this Option and continue processing the header 01 - discard the packet The third-highest-order bit 1 - Option Data may change en-route Option Type - 112 (temporary value) Option Length - 4 PMTU - 4 Octets
3.2 Response MAP Option Format The Response MAP Option format is defined to response measured real PMTU as shown in Figure 3. The destination node sends the IP packet with this Response MAP Option format to the source node. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 x 0|1 1 0 0 0|0 0 0 0 0 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P M T U | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Highest-order two bits 00 - Skip over this Option and continue processing the header 01 - discard the packet The third-highest-order bit 0 - Option Data does not change en-route Park,Lee Expires September 2003 [Page 6] INTERNET-DRAFT March 2003 Option Type - 88 (temporary value) Option Length - 4 PMTU - 4 Octets
3.3 Discoverying PMTU with MAP Options The source node sends IP packet with Request MAP Option to the destination node when node is beginning to communicate. Initial MTU value should be its link MTU of the source node. After node receives Response MAP Option with PMTU, the subsequent packets will be sent of course using obtained PMTU. If the first packet with the IPv6 minimum link MTU don't go through the next-hop, its node must not reduce its estimate of the PMTU below the IPv6 minimum link MTU. At this case, node may receive a Packet Too Big message reporting a next-hop MTU that is less than IPv6 minimum link MTU. Then, node must include a Fragment header in those packets. This packet should be composed of the following headers: IPv6 Header Hop-by-Hop Options with Request/Response MAP Option Fragment ... While the packet is passing through nodes en-route, the following action occurs. - Compare PMTU in Request MAP Option and Link MTU of next hop. - Store the smaller value between them on PMTU field of the packet. By doing the same action on routers en-route, PMTU field of the IP packet with Request MAP Option is updated to have minimum PMTU. This is the actual PMTU value. The destination node that receives the IP packet returns back this value to the source node using Response MAP Option. The source node that receives the actual PMTU value determines the transmission length of a packet. However, if all routers don't recognize MAP Options, responsed MTU is not actual PMTU. 3.4 Detecting PMTU with MAP Options As described on Path MTU Discovery [1981], a source node sends IP packet with Request MAP Option to a destination node before the Detection Timer expires so that it wants to increase PMTU value. Default MTU value is link MTU of the source node. This packet should be composed of the following headers: IPv6 Header Hop-by-Hop Options with Request/Response MAP Option Park,Lee Expires September 2003 [Page 7] INTERNET-DRAFT March 2003 While the packet is passing through nodes en-route, the actions are the same as section 3.3 By doing the same action on routers en-route, PMTU field of the IP packet with Response MAP Option is updated to have minimum PMTU. This is the optimal PMTU value. The destination node that receives the IP packet returns back this value to the source node using Response MAP Option. The source node that receives the optimal PMTU value determines the transmission length of a packet. This method can reduce the number of ICMP-Packet Too Big Error message, otherwise happens more frequently. This also reduce waste of network resource. 4. Node Requirements for Discoverying PMTU 4.1 Source Node and Destination Node When the IPv6 source node has a large amount of packets to send to the destination node, the source node sends the IP packet with Request MAP Option to the destination when node is beginning. The PMTU field of Request MAP Option of the packet initialized by the value of its link MTU of the source node. If router does not understand the MAP Options, the packet is skipped over this Option and continue processing the header (See section 3.). When node receives the Packet Too Big message this node should be performed existing PMTU as [1981]. Whenever the destination node receives the IP packet with Request MAP Option, it must response the IP packet with Response MAP Option immediately. By the Option Type, this packet cannot be modified by routers on routing path. 4.2 Nodes on Routing Path Nodes on a routing path are routers. When the IP packet with Request MAP Option arrives on these routers, they compare the PMTU in Request MAP Option and link MTU of the next hop. They select a smaller value between them and forward the packet with a PMTU value. After doing the same procedure, the final destination node comes to know minimum PMTU. If the IP packet with Response MAP Option arrives on theses routers, they forward the packet without any modification. If routers can not recognize two MAP Options, it skips over this Option and continue processing the header since the first two bits of the MAP Option is 00. (See section 3.). 4.3 Operation Procedure When the IPv6 source node sends to the destination node, the source node sends the IP packet with Request MAP Option and its link MTU of the source node to a destination. In this case, the Option Type in Request MAP Option is 112 (temporary value). While the packet is Park,Lee Expires September 2003 [Page 8] INTERNET-DRAFT March 2003 en-route, intermediate routers compare the PMTU in Request MAP Option and link MTU of the next hop. They select a smaller value between them, store the value to PMTU field of Request MAP Option and forward the packet with the updated PMTU. PMTU of the packet arrived at the destination node becomes minimum PMTU. The destination node sends the IP packet Response MAP Option to inform the source node. In this case, the Option Type in Request MAP Option is 88 (temporary value). After then, the source node sends packets using new PMTU. If routers implements only previous PMTU Discovery [1981] on routing path, in this case the router can skip over this Option and continue processing the header. If node receives the Packet Too Big message, the source node should be performed existing PMTU as [1981]. If node receives Response MAP Option, the source node must compare with its own MTU value. The source node selects a smaller value between them and store. Therefore, in discovering PMTU, the proposed method can eliminate the chance of occurrence of several iterations of the discovery cycle. 5. Node Requirements for Detecting PMTU 5.1 Source Node and Destination Node A source node does not change the PMTU value for some amount of time after it comes to know PMTU based on PMTU Discovery [1981]. When the source node wants to increase PMTU by the Detection Timer, it sends the IP packet with MAP Options to a destination. The PMTU field of MAP Options of the packet contains the value of link MTU of the source node and the data. Whenever a destination node receives the IP packet with Request MAP Option, it must response the IP packet with Response MAP Option immediately. By the Option Type, this packet cannot be modified by routers on routing path. Also, it can use both type "00" and "01". It depends on operator policy. In order to use type "01", source node must have its timer, Response Timer. 5.2 Nodes on Routing Path This processing is same as section 4.2 5.3 Operation Procedure When the source node wants to increase PMTU by the Detection Timer, it sends the IP packet with Request MAP Option to a destination. In this case, the Option Type in Request MAP Option is 112 (temporary value). While the packet is en-route, intermediate routers compare the PMTU in MAP Option and link MTU of the next hop. They select a smaller value between them, store the value to PMTU field of MAP Option and forward the packet with the updated PMTU. PMTU of the packet arrived at the destination node becomes minimum PMTU. The destination node sends the IP packet Response MAP Option to inform the source node. In Park,Lee Expires September 2003 [Page 9] INTERNET-DRAFT March 2003 this case, the Option Type in Response MAP Option is 88 (temporary value). After then, the source node sends packets using new PMTU.if routers implements only previous PMTU Discovery [1981] on routing path, in this case the router can silently discard the packet without response error message by the highest-order two bits, 01, in Option Type field or skip over this Option and continue processing the header with MAP Options by the highest-order two bits, 00, in Option Type field. If the source node does not receive the IP packet with Response MAP Option until the Response Timer expires, the source node initially assumes that the PMTU of a path is the MTU of the first hop in the path as [1981]. 6. Comparison with [1981] This section should be discussed more detail. o In order to perform PMTU, [1981] uses ICMPv6, but MAP uses only basic IPv6 protocol and extension header with newly Option. We assure that it should be implemented very easy in host and router as well. o In the aspect of implementation, all IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification. o As described in [1981], MAP should consider all implementation issues. 7. Security Considerations As we knew, existing PMTU [1981] mechanism makes possible two denial -of-service attacks, most of all, both are based on a malicious party sending false Packet Too Big messages to a victim. Accordingly both weak points, it will result in suboptimal performance and availability of denial-of-service attacks. MAP mechanism is not likely to do denial-of-service attacks. However when malicious node sends false MAP response with its correct type, there are still simpler denial-of-service attacks available. This document considers the protection method from various attacks. In order to avoid spoofing or attacking with incorrect response, MAP mechanisms can use the 64-bit Nonce field. Its value in a MAP Option is always copied from the corresponding Request MAP by the responder. This method is an Optional, therefore the usage of this method depends on operator. However this document recommends this method is implemented with MAP Options for the secure PMTU. Park,Lee Expires September 2003 [Page 10] INTERNET-DRAFT March 2003 +... + | Original IPv6 Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | 1 |MAP Option Typ |0 0 0 0 1 1 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nonce | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Data(PMTU) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Nonce should be a random or good pseudo-random value to foil spoofed replied. An implementation which allows multiple independent processes to send MAP Option may use the Nonce value to deliver MAP Option to the correct process. Nonetheless, such processes must check the received Nonce and ignore extraneous response. 8. Normative Reference [1981] J. McCann, S. Deering, J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. 9. Informative References [2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)", RFC 2460, December 1998. [2463] A. conta, S. Deering, "Internet Control message Protocol (ICMP) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. 9. Acknowledgements The authors would like to thank Robert Hinden for his careful reviews of this draft. 10. Authors' Addresses Soohong Daniel Park SAMSUNG Electronics Digital Media R&D Center Tel : +82-31-200-3728 Fax : +82-31-200-3147 E-mail : soohong.park@samsung.com Park,Lee Expires September 2003 [Page 11] INTERNET-DRAFT March 2003 Hakgoo Lee SAMSUNG Electronics Digital Media R&D Center Tel : +82-31-200-9309 Fax : +82-31-200-3147 E-mail : solited@samsung.co.kr 11. Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12. Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Park,Lee Expires September 2003 [Page 12] INTERNET-DRAFT March 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Park,Lee Expires September 2003 [Page 13] --Boundary_(ID_tDlCzlI4o13z0VWY8crRNw)-- -------------------------------------------------------------------- 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 Mar 7 21:32:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h285WQ7f012158; Fri, 7 Mar 2003 21:32:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h285WP9U012157; Fri, 7 Mar 2003 21:32:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h285WM7f012147 for ; Fri, 7 Mar 2003 21:32:22 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h285WUYt017046 for ; Fri, 7 Mar 2003 21:32:31 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA01276 for ; Fri, 7 Mar 2003 21:32:25 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:32:23 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:30:16 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:32:23 Z Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 05:32:22 Z Disposition-notification-to: soohong.park@samsung.com Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBF00C010OBYA@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 08 Mar 2003 14:31:23 +0900 (KST) Received: from ep_mmp1 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBF00C2J0OAVX@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 08 Mar 2003 14:31:22 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBF00KQR16T3H@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Sat, 08 Mar 2003 14:42:29 +0900 (KST) Date: Sat, 08 Mar 2003 14:31:03 +0900 From: Soohong Daniel Park Subject: [Draft] The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header To: ipng@sunroof.eng.sun.com Message-Id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear folks. I'd like to discuss this draft "The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header", it's not submitted yet. Before I propose, I want to listen some comments and opinion from IPv6 folks. I'll attach this draft. Please look into and response. Daniel ---------------------------------------------------------------- Abstract This document presents a new method for the PMTU discovery for IPv6. To discover the PMTU of a path, a source node measures its actual PMTU using the newly defined Hop-by-Hop Option header, whereas a source node initially assumes that the PMTU of a path is the known MTU of the first hop in the path in the previous one [1981]. In order to measure the actual PMTU, the source node sends the IP packet with the newly defined Hop-by-Hop Option header to the destination node with the first data packet when node is beginning. This can eliminate the chance of occurrence of several iterations of the somewhat complex discovery cycle (sending a packet, receiving a Packet Too Big message, reducing a packet size). Most of all, since existing PMTU has a weak point for security and denial-of-service attacks, this document suggests a security function when PMTU is going on. All IPv6 nodes, including both hosts and routers, must implement newly Options as defined in this specification. ============================================== Soohong Daniel Park Researcher Mobile Platform Lab, Samsung electronics TEL:+82-31-200-3728 FAX:+82-31-200-3147 mailto:Soohong.Park@samsung.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 Mar 8 00:45:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h288jU7f013211; Sat, 8 Mar 2003 00:45:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h288jUHo013210; Sat, 8 Mar 2003 00:45:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h288jR7f013203 for ; Sat, 8 Mar 2003 00:45:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h288javx005539 for ; Sat, 8 Mar 2003 00:45:36 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15152 for ; Sat, 8 Mar 2003 01:45:30 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 08:45:29 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 08:45:29 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 08:45:29 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 08:45:28 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BEC0C6A902 for ; Sat, 8 Mar 2003 10:45:27 +0200 (EET) Message-Id: <3E69AD76.9040401@kolumbus.fi> Date: Sat, 08 Mar 2003 10:44:38 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipv6-node-requirements-03.txt References: <200303072034.PAA29158@ietf.org> In-Reply-To: <200303072034.PAA29158@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those that wish to know what has changed, see the following links: http://www.piuha.net/~jarkko/publications/ipv6/draft-ietf-ipv6-node-requirements-03diff.html http://www.piuha.net/~jarkko/publications/ipv6/draft-ietf-ipv6-node-requirements-03cb.txt (Generated using chbars, a tool by Henrik Levkowetz.) John, your table of contents is wrong for section 7. Also, 7.3 indentation is wrong. Section 1.2 appears twice -- time to upgrade to xml2rfc from nroff? ;-) Jari -------------------------------------------------------------------- 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 Mar 8 08:40:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28GeN7f014270; Sat, 8 Mar 2003 08:40:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28GeN3q014269; Sat, 8 Mar 2003 08:40:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28GeK7f014262 for ; Sat, 8 Mar 2003 08:40:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28GeSYt012255 for ; Sat, 8 Mar 2003 08:40:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13731 for ; Sat, 8 Mar 2003 09:40:22 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:40:20 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:40:13 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:40:13 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:40:13 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA07915 for ; Sat, 8 Mar 2003 16:40:11 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA23449 for ; Sat, 8 Mar 2003 16:40:11 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h28GeBC01795 for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:40:11 GMT Date: Sat, 8 Mar 2003 16:40:11 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] Message-Id: <20030308164011.GS615@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <200303051817.h25IHcY20379@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Mar 06, 2003 at 04:46:14PM +0200, Pekka Savola wrote: > > So, basically if one believes roaming users or DNS-based configuration > would be nice, some easy DNS resolver configuration mechanism would be > "very nice". What happened to the RA-piggyback mechanism? 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 Sat Mar 8 08:46:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28Gk07f014464; Sat, 8 Mar 2003 08:46:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28Gk07T014463; Sat, 8 Mar 2003 08:46:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28Gjv7f014456 for ; Sat, 8 Mar 2003 08:45:57 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28Gk5vx009546 for ; Sat, 8 Mar 2003 08:46:05 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05898 for ; Sat, 8 Mar 2003 08:45:59 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:45:53 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:43:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:45:52 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 16:45:52 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h28GjFe05130; Sat, 8 Mar 2003 18:45:15 +0200 Date: Sat, 8 Mar 2003 18:45:15 +0200 (EET) From: Pekka Savola To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] In-Reply-To: <20030308164011.GS615@login.ecs.soton.ac.uk> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 8 Mar 2003, Tim Chown wrote: > On Thu, Mar 06, 2003 at 04:46:14PM +0200, Pekka Savola wrote: > > > > So, basically if one believes roaming users or DNS-based configuration > > would be nice, some easy DNS resolver configuration mechanism would be > > "very nice". > > What happened to the RA-piggyback mechanism? No comments from the w.g. except by me and the author. RA-piggybacking has a few different nuances, and I'm not sure if I think the one proposed is necessarily the best one, but it's the one group of solutions I'd probably follow up if I wanted to achieve something. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 8 09:08:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28H8G7f014926; Sat, 8 Mar 2003 09:08:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28H8GxA014925; Sat, 8 Mar 2003 09:08:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28H8D7f014918 for ; Sat, 8 Mar 2003 09:08:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28H8KYt016742 for ; Sat, 8 Mar 2003 09:08:21 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25182 for ; Sat, 8 Mar 2003 10:08:15 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:08:15 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:08:15 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:08:14 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:08:14 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA08809 for ; Sat, 8 Mar 2003 17:08:13 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA23741 for ; Sat, 8 Mar 2003 17:08:12 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h28H8CW01929 for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:08:12 GMT Date: Sat, 8 Mar 2003 17:08:12 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] Message-Id: <20030308170812.GY615@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030308164011.GS615@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Mar 08, 2003 at 06:45:15PM +0200, Pekka Savola wrote: > > No comments from the w.g. except by me and the author. > > RA-piggybacking has a few different nuances, and I'm not sure if I think > the one proposed is necessarily the best one, but it's the one group of > solutions I'd probably follow up if I wanted to achieve something. I'd like to see it kept on the table. I appreciate it has security issues, but then all the tabled methods do too? 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 Sat Mar 8 09:27:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28HRI7f015359; Sat, 8 Mar 2003 09:27:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28HRI32015358; Sat, 8 Mar 2003 09:27:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28HRD7f015351 for ; Sat, 8 Mar 2003 09:27:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28HRLvx014744 for ; Sat, 8 Mar 2003 09:27:22 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27941 for ; Sat, 8 Mar 2003 10:27:16 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:27:16 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:27:15 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:27:15 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 17:27:14 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 99F4115210 for ; Sun, 9 Mar 2003 02:28:01 +0900 (JST) Date: Sun, 09 Mar 2003 02:27:29 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: changes in rfc2292bis-09 User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I'm posting this since I was asked about the changes in the new revision privately.) As you may have noticed, I submitted a new revision of the advanced API draft, draft-ietf-ipngwg-rfc2292bis-09.txt. This is a very minor revise to be sent to the IESG, and should not require any changes to implementations that are already compliant to the previous revision. More precisely, the changes in 09 are: 1. corrected the usage example of the IPV6_DONTFRAG socket option (as pointed out in this list): -setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on)); +setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(on)); 2. simplified the change history so that it only consists of changes since RFC 2292, which is necessary for the draft to become an RFC. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 8 14:00:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28M0O7f015948; Sat, 8 Mar 2003 14:00:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28M0OVd015947; Sat, 8 Mar 2003 14:00:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28M0K7f015940 for ; Sat, 8 Mar 2003 14:00:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28M0RYt023128 for ; Sat, 8 Mar 2003 14:00:28 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06633 for ; Sat, 8 Mar 2003 15:00:22 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 21:59:33 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 21:59:33 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 21:59:33 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 21:59:32 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 768C215210; Sun, 9 Mar 2003 07:00:17 +0900 (JST) Date: Sun, 09 Mar 2003 06:59:43 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Ole Troan , Ralph Droms , , Subject: Re: WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt In-Reply-To: References: <7t5znoiwouv.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 27 Feb 2003 09:35:52 +0200 (EET), >>>>> Pekka Savola said: >> > cover even all the theoretical cases. I'd much rather see a very simple >> > basic version of prefix delegation which can be used to get started. >> > There's no way we could anticipate what will be needed in 3-5 years and we >> > could further define the extensions when they're needed. >> >> well, I have to disagree with you there. keeping PD consistent with >> other DHCP options makes for an easier understanding of how it works >> and for a simpler implementation. the fundamental idea behind using >> DHCP for PD is to re-use the existing DHCP infrastructure including >> option semantics. Distilled into one line: "Prefix Delegation with >> DHCP is done in exactly the same way as address assignment with DHCP is". > I can live with that. > I hear many (two sets of groups) are implementing DHCPv6 either for: > - configuration parameters > - prefix delegation (for the lack of alternatives) > If you don't want address assignment in DHCP, doing it the same way in PD > may seem like a burden. (Just for the record) As an implementor of dhcpv6 (for prefix delegation), I agree with Ole; Keeping PD consistent with other DHCP options is not a burden. It rather made the PD specification clearer and helps implemented it. In fact, the base DHCPv6 spec contains generic notions for stateful resources, such as Identity Associations and binding. The unfortunate thing, however, is that the base spec is still too specific to address allocation than it could be. Again, I, as an implementor, support keeping PD consistent with base DHCPv6 despite the "unfortunate" part. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 8 14:05:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28M5C7f016024; Sat, 8 Mar 2003 14:05:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28M5Cfv016023; Sat, 8 Mar 2003 14:05:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28M577f016016 for ; Sat, 8 Mar 2003 14:05:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28M5FYt023684 for ; Sat, 8 Mar 2003 14:05:16 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08579 for ; Sat, 8 Mar 2003 15:05:10 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 22:05:10 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 22:05:09 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 22:05:09 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 22:05:09 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5080E15213; Sun, 9 Mar 2003 07:05:57 +0900 (JST) Date: Sun, 09 Mar 2003 07:05:23 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: "IPV6 WG" Subject: Re: RFC 3041 clarification requested In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 23 Feb 2003 07:25:37 -0800, >>>>> "Richard Draves" said: >> > You do not generate link-local addresses for the new IIDs. And not >> > site-local either. Just global addresses. >> >> Why not for site-local addresses? > There's no technical reason you couldn't generate temporary link-local > or site-local addresses. We felt that within a link/site, privacy is not > so important and so better to avoid the additional overhead. I agree on the link-local case, but I can imagine a user who wants the privacy that temporary addresses provide even within a site. Anyway, in my understanding, draft-ietf-ipngwg-temp-addresses-v2-00 does not prohibit the host from creating site-local temporary addresses, right? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 8 15:17:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28NHB7f016556; Sat, 8 Mar 2003 15:17:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28NHB65016555; Sat, 8 Mar 2003 15:17:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28NH77f016548 for ; Sat, 8 Mar 2003 15:17:07 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28NHFYt002287 for ; Sat, 8 Mar 2003 15:17:15 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24881 for ; Sat, 8 Mar 2003 15:17:09 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:16:42 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:16:42 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:16:42 Z Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:16:40 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h28NGVEY007944; Sat, 8 Mar 2003 15:16:32 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA29884; Sat, 8 Mar 2003 23:16:31 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) From: Ole Troan Date: Sat, 08 Mar 2003 23:16:31 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Thu, 06 Mar 2003 16:14:05 +0900") Message-Id: <7t5el5h5u0g.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei-san, >>> 2. Section 11.1 now specifies the requesting router to use >>> Rebind/Reply exchanges to verify an existing binding (instead of >>> Renew/Reply exchanges). According to the very recent >>> clarifications on the base DHCPv6 spec, however, I'm not sure if >>> Rebind is appropriate here; the server should drop the Rebind >>> message unless it has an explicit knowledge about the validity or >>> invalidity of the prefix, which should not be the case (e.g.) when >>> the upstream link flaps. > >> Rebind now behaves just like Confirm. if by link flap you mean change >> of link to another delegating router, the delegating router can reply >> to a Rebind even without a binding if it knows through explicit >> configuration that the prefixes in the IA_PD is not valid for the link. > > Are you referring to the following part of > draft-ietf-dhc-dhcpv6-interop-00.txt? > > 1. Response of servers to Renew and Rebind messages, sections 18.2.3 and > 18.2.4 > > Resolution: Leave the sentence in section 18.2.3 unchanged. Replace > the sentence in section 18.2.4 with the following text: > > If the server cannot find a client entry for the IA and the > server determines that the addresses in the IA are not > appropriate for the link to which the client's interface is > attached according to the server's explicit configuration > information, the server MAY send a Reply message to the client > containing the client's IA, with the lifetimes for the > addresses in the IA set to zero. This Reply constitutes an > explicit notification to the client that the addresses in the > IA are no longer valid. In this situation, if the server does > not send a Reply message it silently discards the Rebind > message. > > The problem here is that this is a MAY requirement and that "explicit > configuration information" is ambiguous. > > Since this is a MAY, the delegating router (i.e. server) MAY NOT send > a Reply message, which will cause a bad effect (that the invalid > prefix is going to be used). For the case of address assignment, this > should be a minor issue, because this situation only happens when none > of the events to issue a Confirm happen but the upstream router has > somehow been swapped. Rebind is only done for 10 seconds (using Confirms timers), then the client goes back to Solicit state. I don't think we can mandate that a delegating router will know in all cases that a prefix is valid for a link or not. I think we should keep the same text and reasoning as in the base spec. could any of the DHCPv6 base spec guys answer why this is a MAY, as it does delay detection of movement. > For the PD case, however, we don't have Confirm/Reply exchanges. So > the requirement level should be stronger enough. we do. just that we have to use a Rebind/Reply exchange using Confirms timers since we want a binding confirmation, rather than just movement detection. > The same argument should apply to the ambiguous of the wording > "explicit configuration information". In my understanding, the author > intentionally uses an ambiguous term because this is a very minor case > and there can be a (unidentified) trick to build the explicit > information, e.g., a background communication between a primary server > and a secondary one. I don't think "explicit configuration" is ambiguous as such. how a server is configured to know which prefixes are appropriate for a link is implementation dependent. > Again, for the PD case, this is more likely to happen, so we need to > be specific enough. why do you say that? isn't it more likely that a host changes links? what cases do you have in mind? > Thus, I would suggest to add the following text (or something like > this) to the delegating router behavior: > > If the delegating router cannot find a requesting router > entry for the IA_PD and the delegating router determines that > the prefixes in the IA_PD are not appropriate for the > requesting router according to the delegating router's > explicit configuration information, the delegating router > SHOULD send a Reply message to the requesting router > containing the requesting router's IA_PD, with the lifetimes > for the prefixes in the IA_PD set to zero. This Reply > constitutes an explicit notification to the requesting router > that the prefixes in the IA_PD are no longer valid. The > explicit configuration information of the delegating router > contains the fact that the proposed prefixes from the > requesting router is not covered by a prefix for the > organization of the delegating router. > > In summary, I propose to change MAY to SHOULD and to add a concrete > example of "explicit configuration information." > > It would also be helpful to describe how the requesting should react > to this event. requesting router should go to Solicit state. I think this will be made clearer in modified base spec/new PD revision where we'll use NotOnLink rather than lifetimes = 0. cheers, Ole -------------------------------------------------------------------- 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 Mar 8 15:22:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28NMC7f016695; Sat, 8 Mar 2003 15:22:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28NMCZ6016694; Sat, 8 Mar 2003 15:22:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28NM87f016687 for ; Sat, 8 Mar 2003 15:22:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28NMGYt002939 for ; Sat, 8 Mar 2003 15:22:16 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03310 for ; Sat, 8 Mar 2003 16:22:09 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:20:47 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:19:57 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:19:57 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:19:55 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h28NJj0E007751; Sat, 8 Mar 2003 15:19:46 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA29936; Sat, 8 Mar 2003 23:19:45 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: NoPrefixAvail against Solicit (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) From: Ole Troan Date: Sat, 08 Mar 2003 23:19:45 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Thu, 06 Mar 2003 16:18:03 +0900") Message-Id: <7t5bs0l5tv2.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei-san, >>> 3. Section 10.2 contains the following sentence (newly added in the >>> latest revision): >>> >>> If the delegating router cannot delegate any prefixes to an IA_PD in >>> the message from the requesting router, the delegating router MUST >>> include the IA_PD in the Reply message with no prefixes in the IA_PD >>> and a Status Code option in the IA_PD containing status code >>> NoPrefixAvail. >>> >>> I guess the "Reply" should be "Advertisement" here, because this >>> section is talking about "Delegating Router Solicitation." I also >>> guess the sentence was added in response to a question of mine in >>> the ML. If so, a similar clarification should be introduced to >>> Section 11.2 as well. Additionally, the corresponding client >>> behaviors should also be documented. > >> yes, well spotted. > > After re-reading the draft, I now believe this part is just invalid in > Section 10.2 and should be moved to somewhere in Section 11.2. In > fact, NoPrefixAvail in Advertise against Solicit is already documented > in the last paragraph of Section 10.2 you are absolutely right, I'll fix. /ot -------------------------------------------------------------------- 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 Mar 8 15:32:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28NWJ7f017095; Sat, 8 Mar 2003 15:32:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h28NWJ9b017094; Sat, 8 Mar 2003 15:32:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h28NWF7f017084 for ; Sat, 8 Mar 2003 15:32:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h28NWNvx005670 for ; Sat, 8 Mar 2003 15:32:24 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29091 for ; Sat, 8 Mar 2003 15:32:16 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:28:00 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:27:58 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:27:58 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 8 Mar 2003 23:27:55 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h28NRh0E010292; Sat, 8 Mar 2003 15:27:44 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA00021; Sat, 8 Mar 2003 23:27:42 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEI=?= Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: DHCPv6 clarification draft and PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) From: Ole Troan Date: Sat, 08 Mar 2003 23:27:42 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-2022-jp?b?GyRCP0BMQEMjOkgbKEIncw==?= message of "Thu, 06 Mar 2003 16:36:06 +0900") Message-Id: <7t58yvp5tht.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei-san, >>>>>> On Fri, 28 Feb 2003 00:46:37 +0000, >>>>>> Ole Troan said: > >>> 4. The PD draft should reflect some parts of >>> draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections >>> 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft. > >> I have made the changes where appropriate, i.e where we already have >> cut and pasted text from the DHCPv6 base specification. > > I don't think it's enough. For example, Section 8 of > prefix-delegation-02 is almost the exact copy of Section 22.4 of > dhcpv6-28, with s/IA_NA/IA_PD/g and s/address/prefix/g. > > Since Section 2 of dhcpv6-interop-00 proposes to "add" paragraphs to > Section 22.4 of dhcpv6-28, corresponding paragraphs should be added to > Section 8 of prefix-delegation. > > I've not gone thorough the entire issues of the interop draft, but I'm > quite sure that there still exist similar cases. (If you are not > convinced, I'll try to make a complete list.) > >>> We may be able to omit some of them as trivial clarifications, but >>> we should reflect some other part of them because the base DHCPv6 >>> spec (and thus the clarifications for it) is too specific to >>> address assignment. In some cases, implementors can use analogy of >>> the base spec to implement the PD draft, but we should basically >>> provide comprehensive information in the PD draft itself to ensure >>> better interoperability. (As some people, including me, have >>> repeatedly pointed out, the best approach would be to make the base >>> spec generic so that each stateful method can just refer to the >>> base spec. Since we could not make it due to the "it's too late" >>> reason, we should be responsible to implementors for providing >>> detailed information within the PD specification). > >> the PD specification is not meant to be complete and needs to be read >> in conjunction with the base DHCP specification. > > I know (and agree), but I'm saying the PD specification should be > clear wherever a difference between address assignment and prefix > delegation exist. We should be rather redundant than leave the > difference ambiguous. At least please reconsider each issue in the > interop draft and merge necessary changes from it. agree. revision 3 of the PD draft should have most of the issues from the interop document included. the interoperability testing at Connectathon last week showed that the DHCPv6 base spec and PD specifications cannot be that bad. no protocol problems found. /ot -------------------------------------------------------------------- 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 Mar 9 02:55:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h29At17f018148; Sun, 9 Mar 2003 02:55:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h29At1XL018147; Sun, 9 Mar 2003 02:55:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h29Asw7f018140 for ; Sun, 9 Mar 2003 02:54:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h29At6Yt024399 for ; Sun, 9 Mar 2003 02:55:06 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06134 for ; Sun, 9 Mar 2003 03:55:00 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 9 Mar 2003 10:55:00 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 9 Mar 2003 10:54:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 9 Mar 2003 10:54:59 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 9 Mar 2003 10:54:59 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.5]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id CAA23712; Sun, 9 Mar 2003 02:54:51 -0800 (PST) Message-Id: <5.1.0.14.2.20030309055242.066584d8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Mar 2003 05:53:45 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: Re: dual stack & IPv6 on by default Cc: Sebastien Roy , Ronald van der Pol Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI -- A discussion on v6ops that really ought to be happening here, since it concerns the ND RFC. Margaret >To: Ronald van der Pol >cc: Alain Durand , v6ops@ops.ietf.org, jim.Paugh@sun.com >From: Sebastien Roy >Subject: Re: dual stack & IPv6 on by default >Date: Sat, 08 Mar 2003 12:17:25 -0500 > >Ronald, > >Thanks for reading the draft: > >Ronald.vanderPol@rvdp.org said: > > 2. No IPv6 Router > > > > Neighbor Discovery's [1] conceptual sending algorithm dictates that > > when sending a packet to a destination, if a host's default router > > list is empty, then the host assumes that the destination is on-link. > > > > > > Hmm, that sounds reasonable in an IPv6-only environment, but not in a > > dual stack environment. A good example why this document is useful. > >I don't think I see how this would be reasonable even in an IPv6-only >environment. Let's assume there are billions of IPv6 devices out there. >If you have no route (and I do think that at the very least the ND spec >should say route instead of default route in this case) to one of those >billions of devices, what are the odds that it happens to reside on your >link? This bit of ND is an optimization for a very rare case at the >expense of very a common case (you actually can't reach the >destination). Quickly notifying the application that there's no route >to the destination so that the user can correctly configure routes >(on-link or off) seems better than sitting there for minutes while TCP >times out the larval connection. > > > > > 4. Poor IPv6 Network Performance > > > > > > Is this different from IPv4-only networks? In such networks there can > > also be different paths and the path with the lowest cost can have the > > highest packet loss. > >Right, it's no different from an IPv4 or IPv6 only scenario where the >first destination picked for a connection is reachable but has poor >connectivity. One general solution to this problem could be to actually >connect to all destinations in parallel, somehow determine which one has >the best connectivity, and close all of the other ones. I've been told >that this kind of approach has been discussed in a few context at the >IETF. > > > > > > > 4.1. Dealing with Poor IPv6 Network Performance > > > > Not much can be done in this case other than configure each node to > > prefer IPv4 destinations over IPv6. > > > > > > A lot can be done, the network should be fixed :-) I think you mean > > the end host can not do much. > >Right, we should be more clear. > > > Preferring IPv4 over IPv6 could be one > > solution. Another could be disabling IPv6. That may be clearer to the > > end user. It basically says: don't enable IPv6 unless you are sure you > > have good IPv6 connectivity (or know what you are doing). > >Thanks for your input, >-Seb -------------------------------------------------------------------- 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 Mar 9 18:42:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2A2g87f019499; Sun, 9 Mar 2003 18:42:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2A2g8g3019498; Sun, 9 Mar 2003 18:42:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2A2g47f019491 for ; Sun, 9 Mar 2003 18:42:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2A2gBvx006088 for ; Sun, 9 Mar 2003 18:42:12 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27811 for ; Sun, 9 Mar 2003 19:42:04 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 02:39:32 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 02:39:00 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 02:39:00 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 02:38:59 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4389F7DD8 for ; Sun, 9 Mar 2003 21:38:58 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Mar 2003 21:38:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: draft-ietf-ipv6-node-requirements-03.txt Date: Sun, 9 Mar 2003 21:38:57 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03240FF8@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLmrjNegt4zjmrsQlyGF9Q7MMJoPw== From: "Bound, Jim" To: "IPV6 WG" X-OriginalArrivalTime: 10 Mar 2003 02:38:58.0173 (UTC) FILETIME=[3373F2D0:01C2E6AE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2A2g57f019492 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 4.5.5 Stateful Address Autoconfiguration Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] is the standard stateful address configuration protocol. See section 5.3 for details on DHCP. The above MAY should be a SHOULD. There is not mention of stateful support from ND M or O bits being MAY. They simply can be used. It is the option of the user not the standard. To not support any bits suggested for use by users equal to stateless in the ND spec is irresponsible for interoperability requirements in this standards track document. This not being a SHOULD can cause sever interoperability for clients where the user wants all clients to use stateful auto configuration. Any assumption that it will not be used is premature and we should error on the side of it being used. The wording in 5.3 supports the reason for a SHOULD in this section. I could argue it is a MUST but at minimum it is a SHOULD. Regards, /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 Sun Mar 9 19:01:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2A31V7f019845; Sun, 9 Mar 2003 19:01:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2A31VOK019844; Sun, 9 Mar 2003 19:01:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2A31R7f019837 for ; Sun, 9 Mar 2003 19:01:27 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2A31Yvx009213 for ; Sun, 9 Mar 2003 19:01:35 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24810 for ; Sun, 9 Mar 2003 20:01:29 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 03:01:27 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 02:59:14 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 03:01:25 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 03:01:25 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 40B54616B for ; Sun, 9 Mar 2003 22:01:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 9 Mar 2003 22:01:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Sun, 9 Mar 2003 22:01:23 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03240FF9@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLmrjNegt4zjmrsQlyGF9Q7MMJoPwAAQt3w From: "Bound, Jim" To: "IPV6 WG" X-OriginalArrivalTime: 10 Mar 2003 03:01:24.0196 (UTC) FILETIME=[55BEC240:01C2E6B1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2A31S7f019838 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To further support a SHOULD: In 2119 it states: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. The full implications documented in 5.3 in fact are justfication based on RFC 2119 why Stateful Address Configuration for this document should be SHOULD. The M or O bit are valid conditions equal to stateless within the IPv6 architecture. There have been some who would have liked to see stateless only in the architecture but they lost that battle and stateful is as important to the architecture as is stateless. In addition it is a user choice in the market. Implementers who do not wish to support stateful have that choice but we in the IETF have the responsibility to assure interoperable implementations based on the standards that precede the ones we work on later. The default for ND is stateless but the M or O bit imply a condition where the option is in fact used. This nodes requirement document must deal with the end result of all possibilities from ND on the link. One of those is stateful address configuration. From the major interoperability problems that can happen to a users network it should be a SHOULD. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) If the user sets the M or O bit as policy a node that has not implemented stateful address configuration by definition cannot communicate beyond the link. The moment the M or O bit is received the node becomes unable to do the most basic functions for IPv6, which is obtain addresses with a scope greather than link-local. For that reason MAY does not apply. The logic is that making it a SHOULD states that if a market will never use stateful then it is safe and a good reason to not build a product that supports stateful address configuration. Where a MAY implies it is only optional and that is not the case when the M or O bit is received. Regards, /jim >-----Original Message----- >From: Bound, Jim >Sent: Sunday, March 09, 2003 9:39 PM >To: IPV6 WG >Subject: draft-ietf-ipv6-node-requirements-03.txt > > > >4.5.5 Stateful Address Autoconfiguration >Stateful Address Autoconfiguration MAY be supported. DHCP >[DHCPv6] is the standard stateful address configuration >protocol. See section 5.3 for details on DHCP. > >The above MAY should be a SHOULD. There is not mention of >stateful support from ND M or O bits being MAY. They simply >can be used. It is the option of the user not the standard. >To not support any bits suggested for use by users equal to >stateless in the ND spec is irresponsible for interoperability >requirements in this standards track document. This not being >a SHOULD can cause sever interoperability for clients where >the user wants all clients to use stateful auto configuration. > Any assumption that it will not be used is premature and we >should error on the side of it being used. > >The wording in 5.3 supports the reason for a SHOULD in this section. > >I could argue it is a MUST but at minimum it is a SHOULD. > >Regards, >/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 Sun Mar 9 23:34:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2A7YZ7f020828; Sun, 9 Mar 2003 23:34:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2A7YZDb020827; Sun, 9 Mar 2003 23:34:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2A7YW7f020820 for ; Sun, 9 Mar 2003 23:34:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2A7YdYt014391 for ; Sun, 9 Mar 2003 23:34:40 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04378 for ; Sun, 9 Mar 2003 23:34:34 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 07:34:32 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 07:34:32 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 07:34:32 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 07:34:31 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2A7YQA24104; Mon, 10 Mar 2003 09:34:26 +0200 Date: Mon, 10 Mar 2003 09:34:25 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: IPV6 WG Subject: Re: draft-ietf-ipv6-node-requirements-03.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03240FF8@tayexc13.americas.cpqcorp.net> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, On Sun, 9 Mar 2003, Bound, Jim wrote: > 4.5.5 Stateful Address Autoconfiguration > Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] > is the standard stateful address configuration protocol. See section > 5.3 for details on DHCP. > > The above MAY should be a SHOULD. There is not mention of stateful > support from ND M or O bits being MAY. They simply can be used. It is > the option of the user not the standard. To not support any bits > suggested for use by users equal to stateless in the ND spec is > irresponsible for interoperability requirements in this standards track > document. This not being a SHOULD can cause sever interoperability for > clients where the user wants all clients to use stateful auto > configuration. Any assumption that it will not be used is premature and > we should error on the side of it being used. > > The wording in 5.3 supports the reason for a SHOULD in this section. > > I could argue it is a MUST but at minimum it is a SHOULD. I think I can understand your argument here, but let me try to give a different perspective. If the user (I'd call him admin) requires that only stateful auto configuration is acceptable in the network segment by setting a few bits in the advertisement, he should do this only when he knows that all the clients do support these mechanisms. I would not want the requirement for implementing DHCPv6 any stronger that it has to be, ie MAY seems enough (with current experience) -- but I could just maybe accept SHOULD with strong disclaimers and clarifications. Did I understand the issue properly? Or was this about the hosts kernels executing DHCP when receiving M&O bits and "DHCP: file not found" would be an acceptable and a SHOULD-compliant outcome? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 10 06:29:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AET87f023459; Mon, 10 Mar 2003 06:29:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2AET75b023458; Mon, 10 Mar 2003 06:29:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AET47f023451 for ; Mon, 10 Mar 2003 06:29:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AETDvx029570 for ; Mon, 10 Mar 2003 06:29:13 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08195 for ; Mon, 10 Mar 2003 07:29:07 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 14:28:28 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 14:28:28 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 14:28:28 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 14:28:23 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 8C1A17C1A; Mon, 10 Mar 2003 09:28:21 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 09:28:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Mon, 10 Mar 2003 09:28:20 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAC7@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLm14AS/bHP6kfuQZqXsPtL8U7W8gALKWZg From: "Bound, Jim" To: "Pekka Savola" Cc: "IPV6 WG" X-OriginalArrivalTime: 10 Mar 2003 14:28:21.0495 (UTC) FILETIME=[4D2B7870:01C2E711] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2AET47f023452 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, > On Sun, 9 Mar 2003, Bound, Jim wrote: > > 4.5.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration MAY be supported. DHCP > [DHCPv6] is > > the standard stateful address configuration protocol. See > section 5.3 > > for details on DHCP. > > > > The above MAY should be a SHOULD. There is not mention of stateful > > support from ND M or O bits being MAY. They simply can be > used. It > > is the option of the user not the standard. To not support > any bits > > suggested for use by users equal to stateless in the ND spec is > > irresponsible for interoperability requirements in this standards > > track document. This not being a SHOULD can cause sever > > interoperability for clients where the user wants all > clients to use > > stateful auto configuration. Any assumption that it will > not be used > > is premature and we should error on the side of it being used. > > > > The wording in 5.3 supports the reason for a SHOULD in this section. > > > > I could argue it is a MUST but at minimum it is a SHOULD. > > I think I can understand your argument here, but let me try to give a > different perspective. > > If the user (I'd call him admin) requires that only stateful auto > configuration is acceptable in the network segment by setting > a few bits > in the advertisement, he should do this only when he knows > that all the > clients do support these mechanisms. I would agree with that for sure. I would assume when users define their requirements for IPv6 adoption, in many cases, an RFP will be issued to the vendors. Vendors would bid on the RFP, and in the RFP they would be asked do they support DHCPv6 in many cases is my guess. If the RFP wanted DHCPv6 or stateful and the response to the RFP was not supported then the vendor would not win the bid and business would go to a competitor. Say for example MS clients did not support DHCPv6, then Linux desktops would be used or HP-UX did not support DHCPv6 servers, but Solaris did then HP-UX looses. Etc etc etc. So this will all be determined by the market. My fear is that not making it a SHOULD we are giving the wrong impression to the market about the equal support and need for stateful. From: RFC 2461 ND Router Advertisements (and per-prefix flags) allow routers to inform hosts how to perform Address Autoconfiguration. For example, routers can specify whether hosts should use stateful (DHCPv6) and/or autonomous (stateless) address configuration. The exact semantics and usage of the address configuration-related information is specified in [ADDRCONF]. M 1-bit "Managed address configuration" flag. When set, hosts use the administered (stateful) protocol for address autoconfiguration in addition to any addresses autoconfigured using stateless address autoconfiguration. The use of this flag is described in [ADDRCONF]. O 1-bit "Other stateful configuration" flag. When set, hosts use the administered (stateful) protocol for autoconfiguration of other (non-address) information. The use of this flag is described in [ADDRCONF]. In ND we clearly stated either could be used. In additioin the "O" bit is still needed to go retrieve many options not part of ND options or parameters. We are now revisiting the entire DNS Discovery discussion to potentially use stateful. >From RFC 2462 Addrconf: Abstract This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. And.................. IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. Stateful autoconfiguration for IPv6 is the subject of future work [DHCPv6]. END RFC 2462 text. I feel some are also trying to kill stateful and that is wrong. Stateless and Stateful are tools for IPv6 node autoconfiguration. Stateful is one mechanism and not viewed less important than stateless in the spirit of our IPv6 architecture. In addition, as the last sentence from RFC 2462 above states, Stateless and Stateful together can provide a robust solution for nodes. Stateful should be a SHOULD in the node requirements. >I agree the idea is not > it has to be, ie MAY seems enough (with current experience) > -- but I could > just maybe accept SHOULD with strong disclaimers and clarifications. A SHOULD is supportive of the IPv6 architecture. > > Did I understand the issue properly? Or was this about the > hosts kernels executing DHCP when receiving M&O bits and > "DHCP: file not found" would be an acceptable and a > SHOULD-compliant outcome? My issue is about stateless and stateful being required features within IPv6 for auto configuration. Both are needed and both are required. Regards, /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 Mar 10 06:50:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AEoD7f024006; Mon, 10 Mar 2003 06:50:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2AEoDXw024005; Mon, 10 Mar 2003 06:50:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AEo87f023992 for ; Mon, 10 Mar 2003 06:50:09 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2AEo9P29013; Mon, 10 Mar 2003 15:50:10 +0100 (MET) Date: Mon, 10 Mar 2003 15:46:16 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a few comments on anycast mechanisms To: Mika Liljeberg Cc: Erik Nordmark , Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <1046196624.15624.54.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the late response. > True. It is also worth asking what is the proper granularity for storing > the binding: per host, per flow, or something in between? Do we want to > redirect all applications to the same unicast address, or should we > allow different flows go to different unicast addresses? In most cases it shouldn't matter since the routing system will be stable enough so that multiple applications/connections/flows using the same anycast destination will reach the same node. But it makes sense thinking about this when there is routing changes e.g. due to an anycast member failing and routing changes propagating. During such a change does it make sense to allow the old, long-running connections to continue trying to use the old anycast member while new connections having the option to use the new anycast member? > Maybe some basic L3 mechanisms, like the binding cache and RR, could be > made available to applications and transport protocols as a "toolbox" > via an appropriate service interface. Each "anycast user" could then use > this toolbox in the most appropriate way. I think this makes a lot of sense. If anycast takes off we might even see application protocols which know a priori that the destination is anycast, thus the app can invoke the anycast binding protocol before setting up a transport connection. 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 Mar 10 07:03:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AF367f024158; Mon, 10 Mar 2003 07:03:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2AF36RP024155; Mon, 10 Mar 2003 07:03:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AF327f024147 for ; Mon, 10 Mar 2003 07:03:03 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AF369P027123; Mon, 10 Mar 2003 10:03:06 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h2AF3061019459; Mon, 10 Mar 2003 10:03:00 -0500 (EST) Message-Id: <200303101503.h2AF3061019459@strat.East.Sun.COM> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: "Bound, Jim" cc: "Ronald van der Pol" , "Alain Durand" , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: dual stack & IPv6 on by default In-Reply-To: Message from "Bound, Jim" of "Sun, 09 Mar 2003 20:59:26 EST." <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAAC@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Mar 2003 10:03:00 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim.Bound@hp.com said: > The default route would always be known and PPA to send to simply from > RAs, if nothing else were known by the end node. Jim, I'm sorry, I don't understand what you're saying. Can you rephrase it? > > Are you suggesting a change to ND or to configuration of the network as > potential outcome. That's a really good question. I'm not sure what would be the best way to address this. What we're saying in this draft is that operational experience has shown that this part of ND could be problematic in some circumstances. Does ND need to be changed as a result? Probably not. There are no MUST's surrounding that bit of ND. As implementors, we're free to interpret the spec in a sane mannor. With this draft, we're pointing out reasons why implementors may want to be careful with that part of ND. There is informational value in this alone without having to muck with the ND spec itself. -Seb -------------------------------------------------------------------- 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 Mar 10 08:31:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AGVD7f024865; Mon, 10 Mar 2003 08:31:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2AGVDE0024864; Mon, 10 Mar 2003 08:31:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AGV97f024857 for ; Mon, 10 Mar 2003 08:31:10 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AGVD9P019175; Mon, 10 Mar 2003 11:31:14 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.7+Sun/8.12.7) with ESMTP id h2AGV761019763; Mon, 10 Mar 2003 11:31:07 -0500 (EST) Message-Id: <200303101631.h2AGV761019763@strat.East.Sun.COM> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: "Bound, Jim" cc: "Mika Liljeberg" , "Ronald van der Pol" , "Alain Durand" , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: dual stack & IPv6 on by default In-Reply-To: Message from "Bound, Jim" of "Sun, 09 Mar 2003 21:19:36 EST." <9C422444DE99BC46B3AD3C6EAFC9711B03240FF7@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Mar 2003 11:31:07 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim.Bound@hp.com said: > >Ok, I agree that this would be the common case in an IPv6 only > >network. If a random dual stack box that has IPv6 enabled is > >placed in a random network out there, the common case today is > >that it has no IPv6 default router, and this ND rule would be > >problematic for it. That's what we were trying to get across > >in this section of the draft. I suppose we need to more > >explicitly specify in the draft what types of networks we're > >concerned with. > > The worst case scenario would be 1 node coming up on IPv4 network with > IPv6. But then it would have to use transition mechanism to speak IPv6. > Selecting the best method based on the policy of the network > administrator I will assume here. > > Is this a fairly good synopsis of your general concern within this > draft? I'm not sure if I parsed what you wrote above correctly, so I can't say for sure. Just to make sure we're on the same page; The general concern being addressed by this draft is that enabling IPv6 on a dual-stack node in an IPv4 network that may or may not have IPv6 routing support might result in side-effects that the user of that node didn't anticipate or welcome. Some of those are protocol related (ND, ICMPv6, TCP, etc...), and others are administrative. > >> > >> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort > >> immediately when ND determines that the destination is > >unreachable, so > >> TCP does not incur any additional delay here. > > > >Is that stated somewhere (it should be)? Should it be > >explicitly stated in the nodes requirements? In practice, I > >don't think many TCP implementations do this correctly (or as > >you've described), and they should be fixed. > > I believe from my knowledge most TCP implementations do this correctly. > The above rule is very well known by TCP implementers it has nothing to > do with ND or IPv6. With all the specs and all the work why must we > continue to put in specs what is already a defined process that is well > defined. It could very well be that the behavior is well defined to a number of people, and implemented as such in many TCP implementations. How it became well defined is a mystery to me, because RFC 1122 actually suggests (in section 4.2.3.9) to do the opposite of what makes sense in this situation. It says that if TCP receives an ICMP destination unreachable code 0 (no route to destination) or 1 (host unreachable), that it MUST NOT abort the connection. That's in direct conflict with what we're all agreeing is the right thing to do here (to abort the connection if it's in SYN-SENT or SYN-RECEIVED state). > > Even if TCP is > >fixed to abort connections, there is still a 3 second delay in > >IP while NUD is being performed, which may or may not be > > That depends on how NUD cache was built. Your making an implementation > judgement not a standards judgement. Also how one builds the NUD in the > ND spec is a "conceptual" model not a required model just that the state > changes are in fact supported. For all any of us know most have figured > this out to avoid a 3 second delay and its down to 300 nanoseconds. I agree that it's a conceptual model. > > If you want an optimization you should suggest one so we can discuss. My suggested optimization is that you don't assume a destination is on-link just because you don't have a default route. > > >acceptable depending on how many IPv6 destinations the > >application will try before trying IPv4. > > And some applications will never try IPv4 because they are not using > IPv4 anymore for this application. We cannot assume in the logic > premises for this discussion that ALL applications can just use IPv4 > that is an invalid assumption I believe. And an incorrect way to solve > IPv6 node "perceived" problems. True, IPv6-only applications won't have these problems. > > >I can't see this as > >being acceptable when a destination resolves to a few dozen > >IPv6 addresses, for example. > > Your speaking of the route above? Or because of multiple DNS entries? I'm trying to say that if you're assuming that all destinations are on-link because you don't have a default route, as a name resolves to more IPv6 addresses, the delays associated with failed NUD on each address are compounded. > > > An immediate ICMP destination > >unreachable/network unreachable from IP would be generated if > >it didn't assume destinations were on-link. > > So you can't send to nodes not on the same link using host routes? This > is very possible? Absolutely, and that's exacly my point. If you have a host route (or any other route that covers the destination), use it. If you don't have a route, then the destination is unreachable. If you don't have a route to the destination, why try to reach it on-link just in case the destination might happen to be on-link? Is there a situation where this would be useful? -Seb -------------------------------------------------------------------- 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 Mar 10 11:46:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AJkq7f025483; Mon, 10 Mar 2003 11:46:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2AJkqdP025482; Mon, 10 Mar 2003 11:46:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AJkm7f025475 for ; Mon, 10 Mar 2003 11:46:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AJkvYt019549 for ; Mon, 10 Mar 2003 11:46:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16267 for ; Mon, 10 Mar 2003 11:46:52 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 19:46:51 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP; Mon, 10 Mar 2003 19:44:37 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Mon, 10 Mar 2003 19:46:51 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay12.sun.com with ESMTP; Mon, 10 Mar 2003 19:46:49 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2AJl2wY011732; Mon, 10 Mar 2003 21:47:04 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2AJl0E8011728; Mon, 10 Mar 2003 21:47:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: a few comments on anycast mechanisms From: Mika Liljeberg To: Erik Nordmark Cc: Pekka Savola , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047325619.2472.945.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Mar 2003 21:47:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 2003-03-10 at 16:46, Erik Nordmark wrote: > > True. It is also worth asking what is the proper granularity for storing > > the binding: per host, per flow, or something in between? > > In most cases it shouldn't matter since the routing system will be stable > enough so that multiple applications/connections/flows using the same > anycast destination will reach the same node. True. I had some vague thoughts about load balancing using something like random selection rather than route metric but that is probably not a valid use of anycast addressing. > But it makes sense thinking about this when there is routing changes e.g. > due to an anycast member failing and routing changes propagating. > During such a change does it make sense to allow the old, long-running > connections to continue trying to use the old anycast member while new > connections having the option to use the new anycast member? Good point. The binding should probably be deleted if the unicast address becomes unreachable. The best way to do is probably to just let it time out fairly quickly after all transport connections have died away. Changes in routing might also cause another anycast member to become "closer" even if the cached binding is working fine. Does it make sense to try and detect this? Doing so would require the ability to store any old bindings that are still being used by transport connections. MikaL -------------------------------------------------------------------- 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 Mar 10 14:57:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AMvc7f026292; Mon, 10 Mar 2003 14:57:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2AMvcuO026291; Mon, 10 Mar 2003 14:57:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AMvY7f026284 for ; Mon, 10 Mar 2003 14:57:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AMvhYt026977 for ; Mon, 10 Mar 2003 14:57:43 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01406 for ; Mon, 10 Mar 2003 15:57:37 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 22:57:37 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 22:57:36 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 22:57:36 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 22:57:36 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 22848170F; Mon, 10 Mar 2003 17:57:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 17:57:36 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Mon, 10 Mar 2003 17:57:35 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAFE@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLnGt7HGtoieuhoTIq2O3vmq0D6AwAPWd2A From: "Bound, Jim" To: "Sebastien Roy" Cc: "Ronald van der Pol" , "Alain Durand" , , , X-OriginalArrivalTime: 10 Mar 2003 22:57:36.0026 (UTC) FILETIME=[7116E7A0:01C2E758] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2AMvZ7f026285 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Sebastien, >> The default route would always be known and PPA to send to >simply from >> RAs, if nothing else were known by the end node. > >Jim, I'm sorry, I don't understand what you're saying. Can >you rephrase it? When the node hears RAs it can note the router that sent them as implementation feature :--) > >> >> Are you suggesting a change to ND or to configuration of the network >> as potential outcome. > >That's a really good question. I'm not sure what would be the >best way to address this. What we're saying in this draft is >that operational experience has shown that this part of ND >could be problematic in some circumstances. Does ND need to >be changed as a result? Probably not. There are no MUST's >surrounding that bit of ND. As implementors, we're free to >interpret the spec in a sane mannor. With this draft, we're >pointing out reasons why implementors may want to be careful >with that part of ND. There is informational value in this >alone without having to muck with the ND spec itself. I agree. Thanks /jim > >-Seb > > -------------------------------------------------------------------- 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 Mar 10 15:04:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AN477f026491; Mon, 10 Mar 2003 15:04:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2AN47hk026490; Mon, 10 Mar 2003 15:04:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2AN437f026480 for ; Mon, 10 Mar 2003 15:04:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2AN4Cvx000247 for ; Mon, 10 Mar 2003 15:04:12 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17089 for ; Mon, 10 Mar 2003 16:04:06 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:04:05 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:04:04 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:04:04 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:04:04 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 62D717A0F; Mon, 10 Mar 2003 18:04:03 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 18:04:03 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Mon, 10 Mar 2003 18:04:02 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLnInuh7XyF/rHCQFWstbkrDvv1XQANhGCw From: "Bound, Jim" To: "Sebastien Roy" Cc: "Mika Liljeberg" , "Ronald van der Pol" , "Alain Durand" , , , X-OriginalArrivalTime: 10 Mar 2003 23:04:03.0304 (UTC) FILETIME=[57ECD680:01C2E759] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2AN437f026481 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The worst case scenario would be 1 node coming up on IPv4 >network with >> IPv6. But then it would have to use transition mechanism to speak >> IPv6. Selecting the best method based on the policy of the network >> administrator I will assume here. >> >> Is this a fairly good synopsis of your general concern within this >> draft? > >I'm not sure if I parsed what you wrote above correctly, so I >can't say for sure. For edification. I have a node on a work LAN that knows nothing of IPv6. I download software and configure my node to be capable of IPv6. I manually configure my interface to support IPv6. I now ftp to an IPv6 address. This is not going to work. But I was stupid to think it would? Is this the kind of basic mistake your also worried about? > Just to make sure we're on the same page; >The general concern being addressed by this draft is that >enabling IPv6 on a dual-stack node in an IPv4 network that may >or may not have IPv6 routing support might result in >side-effects that the user of that node didn't anticipate or >welcome. Some of those are protocol related (ND, ICMPv6, TCP, >etc...), and others are administrative. But there also could be no problem is my point. I think the draft should state when there is no problem at all. Showing both sides in the draft is important. /jim > >> >> >> >> A TCP connection in SYN-SENT or SYN-RECEIVED states should abort >> >> immediately when ND determines that the destination is >> >unreachable, so >> >> TCP does not incur any additional delay here. >> > >> >Is that stated somewhere (it should be)? Should it be >> >explicitly stated in the nodes requirements? In practice, I >> >don't think many TCP implementations do this correctly (or as >> >you've described), and they should be fixed. >> >> I believe from my knowledge most TCP implementations do this >> correctly. The above rule is very well known by TCP implementers it >> has nothing to do with ND or IPv6. With all the specs and all the >> work why must we continue to put in specs what is already a defined >> process that is well defined. > >It could very well be that the behavior is well defined to a >number of people, and implemented as such in many TCP >implementations. How it became well defined is a mystery to >me, because RFC 1122 actually suggests (in section 4.2.3.9) to >do the opposite of what makes sense in this situation. It >says that if TCP receives an ICMP destination unreachable code >0 (no route to destination) or 1 (host unreachable), that it >MUST NOT abort the connection. That's in direct conflict with >what we're all agreeing is the right thing to do here (to >abort the connection if it's in SYN-SENT or SYN-RECEIVED state). > >> > Even if TCP is >> >fixed to abort connections, there is still a 3 second delay in >> >IP while NUD is being performed, which may or may not be >> >> That depends on how NUD cache was built. Your making an >> implementation judgement not a standards judgement. Also how one >> builds the NUD in the ND spec is a "conceptual" model not a required >> model just that the state changes are in fact supported. >For all any >> of us know most have figured this out to avoid a 3 second delay and >> its down to 300 nanoseconds. > >I agree that it's a conceptual model. > >> >> If you want an optimization you should suggest one so we can discuss. > >My suggested optimization is that you don't assume a >destination is on-link just because you don't have a default route. > >> >> >acceptable depending on how many IPv6 destinations the >> >application will try before trying IPv4. >> >> And some applications will never try IPv4 because they are not using >> IPv4 anymore for this application. We cannot assume in the logic >> premises for this discussion that ALL applications can just use IPv4 >> that is an invalid assumption I believe. And an incorrect way to >> solve IPv6 node "perceived" problems. > >True, IPv6-only applications won't have these problems. > >> >> >I can't see this as >> >being acceptable when a destination resolves to a few dozen >> >IPv6 addresses, for example. >> >> Your speaking of the route above? Or because of multiple >DNS entries? > >I'm trying to say that if you're assuming that all >destinations are on-link because you don't have a default >route, as a name resolves to more IPv6 addresses, the delays >associated with failed NUD on each address are compounded. > >> >> > An immediate ICMP destination >> >unreachable/network unreachable from IP would be generated if >> >it didn't assume destinations were on-link. >> >> So you can't send to nodes not on the same link using host routes? >> This is very possible? > >Absolutely, and that's exacly my point. If you have a host >route (or any other route that covers the destination), use >it. If you don't have a route, then the destination is unreachable. > >If you don't have a route to the destination, why try to reach >it on-link just in case the destination might happen to be >on-link? Is there a situation where this would be useful? > >-Seb > > -------------------------------------------------------------------- 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 Mar 10 15:13:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ANDJ7f026887; Mon, 10 Mar 2003 15:13:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ANDJPu026886; Mon, 10 Mar 2003 15:13:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ANDE7f026879 for ; Mon, 10 Mar 2003 15:13:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ANDNYt002374 for ; Mon, 10 Mar 2003 15:13:23 -0800 (PST) Received: from esunmail ([129.147.58.120]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22733 for ; Mon, 10 Mar 2003 16:13:18 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBK00L423650C@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 16:13:18 -0700 (MST) Received: from sun.com ([129.146.10.23]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBK004OJ364K3@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 16:13:17 -0700 (MST) Date: Mon, 10 Mar 2003 15:13:16 -0800 From: Alain Durand Subject: Re: dual stack & IPv6 on by default To: "Bound, Jim" Cc: Sebastien Roy , Mika Liljeberg , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-id: <3E6D1C0C.80003@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bound, Jim wrote: >For edification. I have a node on a work LAN that knows nothing of IPv6. I >download software and configure my node to be capable of IPv6. I manually >configure my interface to support IPv6. I now ftp to an IPv6 address. This >is not going to work. But I was stupid to think it would? Is this the kind >of basic mistake your also worried about? > Alternate scenario: We ship our system so they configure IPv6 ON by default on all interface. User install this machine on his v4-only network and now experiment larger than usual delays to connect to his favorite servers. User call customer support. This is what I worried about. - Alain. -------------------------------------------------------------------- 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 Mar 10 15:29:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ANTg7f027120; Mon, 10 Mar 2003 15:29:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ANTgJX027119; Mon, 10 Mar 2003 15:29:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ANTd7f027112 for ; Mon, 10 Mar 2003 15:29:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ANTlvx008712 for ; Mon, 10 Mar 2003 15:29:47 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10181 for ; Mon, 10 Mar 2003 16:29:42 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:29:40 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:29:38 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:29:38 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:29:37 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id F10408100; Mon, 10 Mar 2003 18:29:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Mar 2003 18:29:36 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Mon, 10 Mar 2003 18:29:36 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03241001@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLnWqjl+t9x6sKdSkOgJOV6jebUgwAAYUFg From: "Bound, Jim" To: "Alain Durand" Cc: "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , , , X-OriginalArrivalTime: 10 Mar 2003 23:29:36.0911 (UTC) FILETIME=[EA06B1F0:01C2E75C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2ANTd7f027113 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alain, > >>For edification. I have a node on a work LAN that knows nothing of >>IPv6. I download software and configure my node to be >capable of IPv6. >>I manually configure my interface to support IPv6. I now ftp to an >>IPv6 address. This is not going to work. But I was stupid >to think it >>would? Is this the kind of basic mistake your also worried about? >> >Alternate scenario: >We ship our system so they configure IPv6 ON by default on all >interface. User install this machine on his v4-only network >and now experiment larger than usual delays to connect to his >favorite servers. User call customer support. This is what I >worried about. Yep. I know of large user that may require all new systems very soon must be capable of supporting both IPv4 and IPv6. They specifically will require IPv6 not be enabled automaitcally. The reason is that they have gone far beyond Sebastien's draft of potential problems and know not to have it enabled automatically. It is good to document these use issues in the IETF but we need to be responsible to make sure all sides of the coin are depicted. I think it's a thin line where the IETF should work on operational conditions and where they should not. We all say we are so busy and we have the entire problem statement area BOF in San Francisco next week. Part of our problem is we are doing more than what we were mean't to do in the IETF. A lot of these issues are documented in the market but they are not going to publicize it so some of us have to watch it get redone here. Regards, /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 Mar 10 15:51:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ANpD7f027467; Mon, 10 Mar 2003 15:51:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ANpDDF027466; Mon, 10 Mar 2003 15:51:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ANp97f027459 for ; Mon, 10 Mar 2003 15:51:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ANpIvx016416 for ; Mon, 10 Mar 2003 15:51:18 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08909 for ; Mon, 10 Mar 2003 16:51:12 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:51:12 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:51:11 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:51:11 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 10 Mar 2003 23:51:11 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA18482; Mon, 10 Mar 2003 15:51:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2ANp9M03159; Mon, 10 Mar 2003 15:51:09 -0800 X-mProtect: <200303102351> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.99, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdP7mNpH; Mon, 10 Mar 2003 15:51:06 PST Message-Id: <3E6D24E7.60807@iprg.nokia.com> Date: Mon, 10 Mar 2003 15:51:03 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soohong Daniel Park CC: "Fred L. Templin" , ipng@sunroof.eng.sun.com Subject: Re: [Draft] The PMTU Discovery for IPv6 Using Hop-by-Hop Option Header References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Daniel, It is an interesting draft, but I'm afraid you've re-created RFC 1063 (albeit using IPv6 constructs). RFC 1063 was obsoleted by RFC 1191 at least partly due to the requirement that all nodes implement the protocol in order for any useful path MTU information to be obtained on a consistent basis - a feature shared by your proposal. RFC 1063 suggested two methods for implementing such a scheme - Transport Discovery and IP discovery - and it appears you have taken the low road. But, I have seen some evidence lately that an efficient packetization layer MTU discovery mechanism can be realized with no requirement for feedback from the network and no requirement for an explicit probe response from the destination. That said, your draft does give me an idea. An issue for the packetization layer scheme is to provide the lower layers with some way of knowing when a probe is in progress, i.e., so that the lower layers can let the probe through. If the packetization layer were to insert a hop-by-hop (or destination) option that essentially amounted to a no-op, the lower layers could know that a probe was in progress. Your thoughts? Fred Templin ftemplin@iprg.nokia.com Soohong Daniel Park wrote: >Dear folks. > >I'd like to discuss this draft "The PMTU Discovery for IPv6 Using >Hop-by-Hop Option Header", it's not submitted yet. >Before I propose, I want to listen some comments and opinion from IPv6 >folks. >I'll attack this draft. Please look into and response. > > Daniel > > > > -------------------------------------------------------------------- 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 Mar 10 19:47:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2B3lo7f000465; Mon, 10 Mar 2003 19:47:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2B3loKU000464; Mon, 10 Mar 2003 19:47:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2B3lk7f000457 for ; Mon, 10 Mar 2003 19:47:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2B3lsvx029197 for ; Mon, 10 Mar 2003 19:47:55 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07857 for ; Mon, 10 Mar 2003 20:47:49 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 03:47:49 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 03:47:48 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 03:47:47 Z Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 03:47:45 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 97B0C4BC9; Tue, 11 Mar 2003 12:47:40 +0900 (JST) To: Alain Durand Cc: "Bound, Jim" , Sebastien Roy , Mika Liljeberg , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: Alain.Durand's message of Mon, 10 Mar 2003 15:13:16 PST. <3E6D1C0C.80003@sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dual stack & IPv6 on by default From: itojun@iijlab.net Date: Tue, 11 Mar 2003 12:47:40 +0900 Message-Id: <20030311034740.97B0C4BC9@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>For edification. I have a node on a work LAN that knows nothing of IPv6. I >>download software and configure my node to be capable of IPv6. I manually >>configure my interface to support IPv6. I now ftp to an IPv6 address. This >>is not going to work. But I was stupid to think it would? Is this the kind >>of basic mistake your also worried about? >> >Alternate scenario: >We ship our system so they configure IPv6 ON by default on all interface. >User install this machine on his v4-only network and now experiment >larger than usual delays to connect to his favorite servers. >User call customer support. >This is what I worried about. your worry has very little to do with IPv6 itself. this is because of the way we operate IPv6 today (especially in the States) where long-haul tunnels and excessive/nonconsiderate transit is common. another thing is that users would call customer support regardless from the protocol type they're using. IPv4 or IPv6. there's no difference. itojun -------------------------------------------------------------------- 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 Mar 10 22:08:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2B68P7f000904; Mon, 10 Mar 2003 22:08:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2B68PR8000903; Mon, 10 Mar 2003 22:08:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2B68M7f000896 for ; Mon, 10 Mar 2003 22:08:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2B68VYt016615 for ; Mon, 10 Mar 2003 22:08:31 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11176 for ; Mon, 10 Mar 2003 23:08:25 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 06:08:25 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP; Tue, 11 Mar 2003 06:08:25 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Tue, 11 Mar 2003 06:08:24 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP; Tue, 11 Mar 2003 06:08:24 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2B68Lf00412; Tue, 11 Mar 2003 08:08:21 +0200 Date: Tue, 11 Mar 2003 08:08:21 +0200 (EET) From: Pekka Savola To: Alain Durand cc: "Bound, Jim" , Sebastien Roy , Mika Liljeberg , Ronald van der Pol , , , Subject: Re: dual stack & IPv6 on by default In-Reply-To: <3E6D1C0C.80003@sun.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 10 Mar 2003, Alain Durand wrote: > >For edification. I have a node on a work LAN that knows nothing of IPv6. I > >download software and configure my node to be capable of IPv6. I manually > >configure my interface to support IPv6. I now ftp to an IPv6 address. This > >is not going to work. But I was stupid to think it would? Is this the kind > >of basic mistake your also worried about? > > > Alternate scenario: > We ship our system so they configure IPv6 ON by default on all interface. > User install this machine on his v4-only network and now experiment > larger than usual delays to connect to his favorite servers. > User call customer support. > This is what I worried about. How do the delays get longer, I wonder? Different flavors of BSD have shipped v6-enabled by default since, about 2000 or 2001, I don't remember anymore, and I've never seen anyone complain about increased delays. I don't think there should be any significant potential drawback *until* the system is configured with a non-link-local address. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 11 02:30:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BAUs7f001593; Tue, 11 Mar 2003 02:30:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BAUrkg001592; Tue, 11 Mar 2003 02:30:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BAUo7f001585 for ; Tue, 11 Mar 2003 02:30:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BAUxvx012597 for ; Tue, 11 Mar 2003 02:30:59 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08059 for ; Tue, 11 Mar 2003 03:30:52 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 10:30:48 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 10:30:44 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 10:30:44 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 10:30:40 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2BAU7EO059246; Tue, 11 Mar 2003 11:30:07 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2BATrbn207514; Tue, 11 Mar 2003 11:30:02 +0100 Received: from dhcp222-59.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56254 from ; Tue, 11 Mar 2003 11:29:51 +0100 Message-Id: <3E6DBA64.8BF8847A@hursley.ibm.com> Date: Tue, 11 Mar 2003 11:28:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: Pekka Savola , IPV6 WG Subject: Re: draft-ietf-ipv6-node-requirements-03.txt References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCAC7@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Bound, Jim" wrote: much deleted... ... > My issue is about stateless and stateful being required features within > IPv6 for auto configuration. Both are needed and both are required. I hope we all agree on this, using lower case. I think we have a genuine problem here in they way RFC 2119 defines SHOULD - it makes it very strong indeed, maybe a bit too strong for this case, whereas MAY is clearly too weak. Maybe indeed we need to qualify the SHOULD, e.g. Stateful Address Autoconfiguration SHOULD be supported, unless all possible use cases for the specific implementation concerned are clearly satisfied by Stateless Address Autoconfiguration. Brian -------------------------------------------------------------------- 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 Mar 11 04:35:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BCZS7f002150; Tue, 11 Mar 2003 04:35:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BCZSbe002149; Tue, 11 Mar 2003 04:35:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BCZP7f002142 for ; Tue, 11 Mar 2003 04:35:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BCZKvx003418 for ; Tue, 11 Mar 2003 04:35:21 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05722 for ; Tue, 11 Mar 2003 05:35:14 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:35:13 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:35:11 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:35:11 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:35:10 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 42182153F; Tue, 11 Mar 2003 07:35:10 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 07:34:37 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Tue, 11 Mar 2003 07:34:37 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB26@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLnuT01xsguF83qRFepTB+NDkS42AAEUsUQ From: "Bound, Jim" To: "Brian E Carpenter" Cc: "Pekka Savola" , "IPV6 WG" X-OriginalArrivalTime: 11 Mar 2003 12:34:37.0720 (UTC) FILETIME=[944BC980:01C2E7CA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2BCZP7f002143 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I like Brian's suggestion folks. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, March 11, 2003 5:29 AM > To: Bound, Jim > Cc: Pekka Savola; IPV6 WG > Subject: Re: draft-ietf-ipv6-node-requirements-03.txt > > > "Bound, Jim" wrote: > > much deleted... > ... > > My issue is about stateless and stateful being required features > > within IPv6 for auto configuration. Both are needed and both are > > required. > > I hope we all agree on this, using lower case. I think we > have a genuine problem here in they way RFC 2119 defines > SHOULD - it makes it very strong indeed, maybe a bit too > strong for this case, whereas MAY is clearly too weak. Maybe > indeed we need to qualify the SHOULD, e.g. > > Stateful Address Autoconfiguration SHOULD be supported, unless all > possible use cases for the specific implementation concerned > are clearly satisfied by Stateless Address Autoconfiguration. > > Brian > -------------------------------------------------------------------- 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 Mar 11 04:57:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BCvp7f002499; Tue, 11 Mar 2003 04:57:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BCvpn8002498; Tue, 11 Mar 2003 04:57:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BCvm7f002491 for ; Tue, 11 Mar 2003 04:57:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BCvuYt022343 for ; Tue, 11 Mar 2003 04:57:56 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22764 for ; Tue, 11 Mar 2003 04:57:50 -0800 (PST) From: john.loughney@nokia.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:57:50 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:55:34 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:57:49 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 12:57:49 Z Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2BD1EF05449 for ; Tue, 11 Mar 2003 15:01:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Mar 2003 14:57:47 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:57:47 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Mar 2003 14:57:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Tue, 11 Mar 2003 14:57:46 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLnuT01xsguF83qRFepTB+NDkS42AAEUsUQAADOIwA= To: , Cc: X-OriginalArrivalTime: 11 Mar 2003 12:57:47.0188 (UTC) FILETIME=[D07BC740:01C2E7CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2BCvm7f002492 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, I agree, I think it is a good compromise. > I like Brian's suggestion folks. > /jim > > > "Bound, Jim" wrote: > > > > much deleted... > > ... > > > My issue is about stateless and stateful being required features > > > within IPv6 for auto configuration. Both are needed and both are > > > required. > > > > I hope we all agree on this, using lower case. I think we > > have a genuine problem here in they way RFC 2119 defines > > SHOULD - it makes it very strong indeed, maybe a bit too > > strong for this case, whereas MAY is clearly too weak. Maybe > > indeed we need to qualify the SHOULD, e.g. > > > > Stateful Address Autoconfiguration SHOULD be supported, unless all > > possible use cases for the specific implementation concerned > > are clearly satisfied by Stateless Address Autoconfiguration. > > > > Brian -------------------------------------------------------------------- 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 Mar 11 05:31:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BDVg7f003011; Tue, 11 Mar 2003 05:31:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BDVgsM003010; Tue, 11 Mar 2003 05:31:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BDVd7f003003 for ; Tue, 11 Mar 2003 05:31:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BDVkvx012666 for ; Tue, 11 Mar 2003 05:31:46 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10055 for ; Tue, 11 Mar 2003 06:31:41 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.Sun.COM; Tue, 11 Mar 2003 13:31:21 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.Sun.COM; Tue, 11 Mar 2003 13:31:11 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.Sun.COM; Tue, 11 Mar 2003 13:31:11 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.Sun.COM; Tue, 11 Mar 2003 13:31:11 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA09938; Tue, 11 Mar 2003 13:31:05 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA15832; Tue, 11 Mar 2003 13:31:04 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2BDV4j28822; Tue, 11 Mar 2003 13:31:04 GMT Date: Tue, 11 Mar 2003 13:31:04 +0000 From: Tim Chown To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default Message-Id: <20030311133104.GM8715@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, ipng@sunroof.eng.Sun.COM References: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 10, 2003 at 06:04:02PM -0500, Bound, Jim wrote: > > For edification. I have a node on a work LAN that knows nothing of > IPv6. I download software and configure my node to be capable of IPv6. > I manually configure my interface to support IPv6. I now ftp to an IPv6 > address. This is not going to work. But I was stupid to think it > would? Is this the kind of basic mistake your also worried about? Agreed if you're static in a network, then that's a mistake. But a common problem is taking an IPv6-enabled device from a "dual stack" network where it happily runs using either protocol into one where only IPv4 is supported. Then what happens varies with OS/browser. For example, in WinXP+MSIE6 any attempt to reach a site with an AAAA (and A) record will fail with an error after 20-60 seconds. With WinXP+Mozilla 1.3 a similar attempt will just get an immediate "connection refused". In neither case is there (the desirable) fallback to IPv4. So for people who want to go dual-stack in their workplace yet take devices to IPv4-only networks that's the problem they face. Of course you get what you deserve maybe for the application writer trusting presence of a DNS record as an indication of connectivity. There will be some user-land settings required for IPv6 connectivity. For example RFC3041 needs to be per application so you can rely on (as many people will want to) per-host IP-based authentication for ssh access, while taking advantage of RFC3041 while browsing the net from the same host. I can see that we can offer users a privacy/fixed IP toggle, and many could understand that as an advanced setting in their TCP/IP options, but it's something we want to shield "typical" users from. I don't believe a userland v4/v6 toggle would be useful for "typical" users. It be used by the v6-geeks in the current stage of deployment, but we need more robust methods for handling movement between dual-stack and IPv4-only networks where IPv6 is enabled on a device. We're paying for the choice of app developers to promote IPv6 by trying IPv6 ahead of IPv4, and then not falling back (quickly) when it fails. 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 Tue Mar 11 05:41:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BDfe7f003393; Tue, 11 Mar 2003 05:41:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BDfeRx003392; Tue, 11 Mar 2003 05:41:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BDfb7f003385 for ; Tue, 11 Mar 2003 05:41:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BDfjYt029532 for ; Tue, 11 Mar 2003 05:41:45 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15127 for ; Tue, 11 Mar 2003 06:41:39 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:41:39 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:41:39 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:41:38 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:41:38 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA10657 for ; Tue, 11 Mar 2003 13:41:37 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA16544 for ; Tue, 11 Mar 2003 13:41:37 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2BDfbT28970 for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:41:37 GMT Date: Tue, 11 Mar 2003 13:41:37 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipv6-node-requirements-03.txt Message-Id: <20030311134137.GO8715@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DNS discovery remains probably the "sticking" issue for need for DHCPv6 in otherwise atatelessly autoconfiguring networks. I agree that the mechanism should be discussed and determined in the DNS WG (dnsext I presume). However, can anyone confirm if there is a slot in dnsext in San Francisco for this issue? There's no agenda on the IETF site. Tim On Tue, Mar 11, 2003 at 02:57:46PM +0200, john.loughney@nokia.com wrote: > Hi Jim, > > I agree, I think it is a good compromise. > > > I like Brian's suggestion folks. > > /jim > > > > > "Bound, Jim" wrote: > > > > > > much deleted... > > > ... > > > > My issue is about stateless and stateful being required features > > > > within IPv6 for auto configuration. Both are needed and both are > > > > required. > > > > > > I hope we all agree on this, using lower case. I think we > > > have a genuine problem here in they way RFC 2119 defines > > > SHOULD - it makes it very strong indeed, maybe a bit too > > > strong for this case, whereas MAY is clearly too weak. Maybe > > > indeed we need to qualify the SHOULD, e.g. > > > > > > Stateful Address Autoconfiguration SHOULD be supported, unless all > > > possible use cases for the specific implementation concerned > > > are clearly satisfied by Stateless Address Autoconfiguration. > > > > > > Brian > > > -------------------------------------------------------------------- > 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 Tue Mar 11 05:44:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BDi07f003451; Tue, 11 Mar 2003 05:44:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BDi00Z003450; Tue, 11 Mar 2003 05:44:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BDhu7f003440 for ; Tue, 11 Mar 2003 05:43:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BDi4vx014798 for ; Tue, 11 Mar 2003 05:44:04 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16350 for ; Tue, 11 Mar 2003 06:43:58 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:43:57 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:41:41 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:43:56 Z Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 13:43:56 Z Received: from newton.cs.uni-bonn.de (newton.cs.uni-bonn.de [131.220.4.212]) by theory.cs.uni-bonn.de (8.12.8/8.12.8) with SMTP id h2BDhmUk002527; Tue, 11 Mar 2003 14:43:48 +0100 (MET) Received: (from ignatios@newton.cs.uni-bonn.de) by newton.cs.uni-bonn.de (mini_sendmail/1.3.2 21nov2002 nb1 15Feb2003); Tue, 11 Mar 2003 14:43:18 CET (sender ignatios@newton.cs.uni-bonn.de) Date: Tue, 11 Mar 2003 14:43:18 +0100 From: Ignatios Souvatzis To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default Message-Id: <20030311134318.GB24974@newton.cs.uni-bonn.de> References: <9C422444DE99BC46B3AD3C6EAFC9711B03241000@tayexc13.americas.cpqcorp.net> <3E6D1C0C.80003@sun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=x-unknown; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline In-Reply-To: <3E6D1C0C.80003@sun.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Mon, Mar 10, 2003 at 03:13:16PM -0800, Alain Durand wrote: > Alternate scenario: > We ship our system so they configure IPv6 ON by default on all interface. > User install this machine on his v4-only network and now experiment > larger than usual delays to connect to his favorite servers. The user won't, because in this case the machine won't get any address prefix and routing information. The trouble comes when the customer's net has a long-delay IPv6 connection. Regards, -is --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPm3n8zCn4om+4LhpAQHTDwgAkMcktlXt9S/w4VoufD2JDQj1Ar0TZGek vuiXqA1G30RD29HdLsyVOUR2skL2T4ODg31ZCs4hfZt1d7sha1/LgvdGLYsmbVq7 VKdtQGRRy1w1ihYnLoie6QHSEvdNJsjepustqXKitPoGJ5x7zZjITM2tj0fymCdc D0Ee7KZhfsUKnff1l394j+MOkT8QTf1RP8lzauFnXKOpS7mwBvF8Ut0twrQ9/jHT C/hG6/43rpOGyDzVI+qSWNhUwBpE05MElGYpLJQow/A9j2864AUfd53JuKEPvvZE /+FZo2B8/MFiRMJWYMIawxQdSGXZDxTDplAVcArGI+5Ju5JdXw+9Cw== =Wjl+ -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- -------------------------------------------------------------------- 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 Mar 11 06:30:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEUN7f004204; Tue, 11 Mar 2003 06:30:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BEUNvS004203; Tue, 11 Mar 2003 06:30:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEUK7f004196 for ; Tue, 11 Mar 2003 06:30:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BEURYt008827 for ; Tue, 11 Mar 2003 06:30:28 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00541 for ; Tue, 11 Mar 2003 07:30:22 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:30:20 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:30:20 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:30:20 Z Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:30:19 Z Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Tue, 11 Mar 2003 15:30:06 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 15:29:44 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Revised IPv6 charter and DNS discovery Date: Tue, 11 Mar 2003 15:29:43 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised IPv6 charter and DNS discovery Thread-Index: AcLjRcvLsssjftDMQzqzWVYS1uQZ3wEizezA From: "BELOEIL Luc FTRD/DMI/CAE" To: "Alain Durand" , "Bill Manning" Cc: , X-OriginalArrivalTime: 11 Mar 2003 14:29:44.0458 (UTC) FILETIME=[A9085EA0:01C2E7DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2BEUK7f004197 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Alain that we need more input/discussion about using well known addresses for discovery of some services. I think that that will impact most of our networks' architectures. I know that a lot of ideas have been already described in former DNS Discovery Design Team(s). It seems that we do not all agree on the level of importance of the services to discover (DNS, NTP, Printers discovery...). I have the feeling that following that level, each of us assumes that the automatic discovery solution is allowed to constraint the network in different way (do we need a third party discovery server ? can we allocate a pre-defined address? ...). Each time, one can also argue that DHCP or SLP - protocols already with an RFC status - can achieve those functions. IMHO it is not clear how to progress. DHCP and SLP might be enough. I would be grateful if someone could help me to understand pros and cons of those solutions (DHCP, SLP) vs pre-defined adresses. my 0,02% Luc > De : Alain Durand [mailto:Alain.Durand@Sun.COM] > Envoye : mercredi 5 mars 2003 19:30 > > On Wednesday, March 5, 2003, at 10:17 AM, Bill Manning wrote: > > > > > As a co-author of a couple of previous DNS discovery IDs, I would > > have to agree that as postulated, the current DNS discovery work > > has pretty much been OBE. (overtaken by events) > > There have been two distinct BOFs on this idea in the last > five years > > so I don't think another BOF will be very productive. > > Bill, > > Note that I'm not suggesting a bof on DNS discovery mechanism per se, > but a bof on generic service discovery using well known, voluntarily > ambiguous > addresses. > > - Alain. > -------------------------------------------------------------------- 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 Mar 11 06:40:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEeS7f004486; Tue, 11 Mar 2003 06:40:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BEeRFb004485; Tue, 11 Mar 2003 06:40:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEeO7f004478 for ; Tue, 11 Mar 2003 06:40:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BEeWYt010958 for ; Tue, 11 Mar 2003 06:40:32 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19231 for ; Tue, 11 Mar 2003 07:40:26 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:40:05 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:37:43 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:39:58 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:39:57 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2BEdN203815; Tue, 11 Mar 2003 16:39:23 +0200 Date: Tue, 11 Mar 2003 16:39:22 +0200 (EET) From: Pekka Savola To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] In-Reply-To: <20030308170812.GY615@login.ecs.soton.ac.uk> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 8 Mar 2003, Tim Chown wrote: > On Sat, Mar 08, 2003 at 06:45:15PM +0200, Pekka Savola wrote: > > > > No comments from the w.g. except by me and the author. > > > > RA-piggybacking has a few different nuances, and I'm not sure if I think > > the one proposed is necessarily the best one, but it's the one group of > > solutions I'd probably follow up if I wanted to achieve something. > > I'd like to see it kept on the table. I appreciate it has security issues, > but then all the tabled methods do too? Actually, the security properties of RA-piggybacking solutions are roughly on the same level as with DHCP and friends, not to mention general connectivity. The only attack model with RA-piggybacking that might make sense is to inject a spoofed RA containing your rogue DNS servers instead of hijacking all the connectivity. This might be more difficult to notice than all net access being man-in-the-middle -attacked on the link by a node. But then again, the above case hasn't been mentioned in any analysis I recall (just made it up), so it's difficult to say. I certainly don't feel there are a lot of issues with security in RA-based DNS discovery. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 11 06:52:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEqB7f004840; Tue, 11 Mar 2003 06:52:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BEqBS5004839; Tue, 11 Mar 2003 06:52:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEq57f004822 for ; Tue, 11 Mar 2003 06:52:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BEqDYt013608 for ; Tue, 11 Mar 2003 06:52:14 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16066 for ; Tue, 11 Mar 2003 06:52:08 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:07 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:07 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:07 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:02 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA17122 for ; Tue, 11 Mar 2003 14:52:00 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA19864 for ; Tue, 11 Mar 2003 14:43:19 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2BEhJt29584 for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:43:19 GMT Date: Tue, 11 Mar 2003 14:43:19 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] Message-Id: <20030311144318.GY8715@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030308170812.GY615@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 11, 2003 at 04:39:22PM +0200, Pekka Savola wrote: > > But then again, the above case hasn't been mentioned in any analysis I > recall (just made it up), so it's difficult to say. I certainly don't > feel there are a lot of issues with security in RA-based DNS discovery. OK, so do you think it;s worth getting it tabled (late) in dnsext in San Francisco (given they have no public agenda yet?) 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 Tue Mar 11 06:52:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEqD7f004843; Tue, 11 Mar 2003 06:52:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BEqDEm004842; Tue, 11 Mar 2003 06:52:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEq67f004829 for ; Tue, 11 Mar 2003 06:52:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BEqEvx003865 for ; Tue, 11 Mar 2003 06:52:14 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26782 for ; Tue, 11 Mar 2003 07:52:08 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:08 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:08 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:07 Z Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:52:07 Z Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2BEnx1K027965; Tue, 11 Mar 2003 09:50:25 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Mar 2003 09:49:29 -0500 Message-Id: <3E6DF802.2020104@nc.rr.com> Date: Tue, 11 Mar 2003 09:51:46 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Tim Chown , ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > On Sat, 8 Mar 2003, Tim Chown wrote: > >>On Sat, Mar 08, 2003 at 06:45:15PM +0200, Pekka Savola wrote: >> >>>No comments from the w.g. except by me and the author. >>> >>>RA-piggybacking has a few different nuances, and I'm not sure if I think >>>the one proposed is necessarily the best one, but it's the one group of >>>solutions I'd probably follow up if I wanted to achieve something. >> >>I'd like to see it kept on the table. I appreciate it has security issues, >>but then all the tabled methods do too? > > > Actually, the security properties of RA-piggybacking solutions are roughly > on the same level as with DHCP and friends, not to mention general > connectivity. > > The only attack model with RA-piggybacking that might make sense is to > inject a spoofed RA containing your rogue DNS servers instead of hijacking > all the connectivity. This might be more difficult to notice than all net > access being man-in-the-middle -attacked on the link by a node. > > But then again, the above case hasn't been mentioned in any analysis I > recall (just made it up), so it's difficult to say. I certainly don't > feel there are a lot of issues with security in RA-based DNS discovery. > I believe section 6.2.7 of RFC 2461 will help catch this kind of attack. If the routers on the link validate the parameters being sent by other routers in their RA's, the spoofed RA should be detected. Brian -------------------------------------------------------------------- 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 Mar 11 06:56:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEu07f005190; Tue, 11 Mar 2003 06:56:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BEtx60005189; Tue, 11 Mar 2003 06:55:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BEtt7f005171 for ; Tue, 11 Mar 2003 06:55:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BEu3Yt014575 for ; Tue, 11 Mar 2003 06:56:03 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29408 for ; Tue, 11 Mar 2003 07:55:57 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:55:17 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:55:17 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:55:16 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:55:16 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D0D6F832A; Tue, 11 Mar 2003 09:55:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 09:55:04 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dual stack & IPv6 on by default Date: Tue, 11 Mar 2003 09:55:04 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB38@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLn0vJI4aALWXQ0T1S+6ms8UGf9hgACqOww From: "Bound, Jim" To: "Tim Chown" , , X-OriginalArrivalTime: 11 Mar 2003 14:55:04.0700 (UTC) FILETIME=[332AE3C0:01C2E7DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2BEtu7f005175 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > So for people who want to go dual-stack in their workplace > yet take devices > to IPv4-only networks that's the problem they face. Of > course you get what > you deserve maybe for the application writer trusting > presence of a DNS > record as an indication of connectivity. This is for me key. I believe in punishment, penalties, and accountability :--) So if you do stupid things you will learn from that. But also we cannot possibly correct every network problem like this in IPv4 or IPv6. Again it is not indicative of just IPv6 but IPv4 too. Also I want to restate. For some if IPv6 don't work then they are dead. Fall back to IPv4 is not an option. I know users who are going to adopt IPv6 with the intention of phasing out IPv4 as quickly as possible and immediately move to dominant IPv6 routing backbones on their Intranet as a strategy. This is also becoming more and more prevalent exponentially too. My guess is they see the cost and decide lets just go to IPv6 as quick as possible and get the pain over with. This view is now as predominant as any other for deployment and I feel many on this list don't "get it". This is not mean't to be negative or a challenge merely a statement. /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 Tue Mar 11 06:59:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BExr7f005727; Tue, 11 Mar 2003 06:59:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BExrQW005726; Tue, 11 Mar 2003 06:59:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BExm7f005709 for ; Tue, 11 Mar 2003 06:59:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BExuvx005859 for ; Tue, 11 Mar 2003 06:59:56 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02045 for ; Tue, 11 Mar 2003 07:59:51 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:59:50 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:59:14 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:59:14 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 14:59:13 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D8AF58298; Tue, 11 Mar 2003 09:59:12 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 09:59:09 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Tue, 11 Mar 2003 09:59:08 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB39@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLnuT01xsguF83qRFepTB+NDkS42AAEUsUQAADOIwAABBzYwA== From: "Bound, Jim" To: , Cc: X-OriginalArrivalTime: 11 Mar 2003 14:59:09.0258 (UTC) FILETIME=[C4EF7AA0:01C2E7DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2BExn7f005711 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It would save me from doing a legal like brief (precedents in the IETF for my case here) and major work to the IESG too :--) But it really can work this way and appease all. Except those who would like to see Stateful dead completely and I would argue they should not win this debate because stateful is an equal partner in the IPv6 architecture. I also question anyones motive that believes stateful should be dead too. In addition the Enterprise wireline networks and IT are not going to give up stateful control with servers and NAS in their networks for a long time with IPv6 is my intelligence from my work with users. /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, March 11, 2003 7:58 AM > To: Bound, Jim; brian@hursley.ibm.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipv6-node-requirements-03.txt > > > Hi Jim, > > I agree, I think it is a good compromise. > > > I like Brian's suggestion folks. > > /jim > > > > > "Bound, Jim" wrote: > > > > > > much deleted... > > > ... > > > > My issue is about stateless and stateful being required features > > > > within IPv6 for auto configuration. Both are needed > and both are > > > > required. > > > > > > I hope we all agree on this, using lower case. I think we > > > have a genuine problem here in they way RFC 2119 defines > > > SHOULD - it makes it very strong indeed, maybe a bit too > > > strong for this case, whereas MAY is clearly too weak. Maybe > > > indeed we need to qualify the SHOULD, e.g. > > > > > > Stateful Address Autoconfiguration SHOULD be supported, unless all > > > possible use cases for the specific implementation concerned > > > are clearly satisfied by Stateless Address Autoconfiguration. > > > > > > Brian > > -------------------------------------------------------------------- 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 Mar 11 08:25:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BGPj7f006842; Tue, 11 Mar 2003 08:25:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BGPjSY006841; Tue, 11 Mar 2003 08:25:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BGPe7f006834 for ; Tue, 11 Mar 2003 08:25:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BGPmYt008670 for ; Tue, 11 Mar 2003 08:25:48 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04748 for ; Tue, 11 Mar 2003 08:25:42 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 16:25:39 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 16:25:39 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 16:25:39 Z Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 16:25:37 Z Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id C735D4CE33; Tue, 11 Mar 2003 11:25:34 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h2BGP7k12099; Tue, 11 Mar 2003 11:25:23 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id C83AB7B6C; Tue, 11 Mar 2003 10:23:45 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Pekka Savola Cc: Alain Durand , "Bound, Jim" , Sebastien Roy , Mika Liljeberg , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default In-Reply-To: Your message of "Tue, 11 Mar 2003 08:08:21 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Mar 2003 10:23:45 -0500 Message-Id: <20030311152345.C83AB7B6C@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Pekka Savola wr ites: >On Mon, 10 Mar 2003, Alain Durand wrote: >> >For edification. I have a node on a work LAN that knows nothing of IPv6. >I >> >download software and configure my node to be capable of IPv6. I manually >> >configure my interface to support IPv6. I now ftp to an IPv6 address. Thi >s >> >is not going to work. But I was stupid to think it would? Is this the kin >d >> >of basic mistake your also worried about? >> > >> Alternate scenario: >> We ship our system so they configure IPv6 ON by default on all interface. >> User install this machine on his v4-only network and now experiment >> larger than usual delays to connect to his favorite servers. >> User call customer support. >> This is what I worried about. > >How do the delays get longer, I wonder? > >Different flavors of BSD have shipped v6-enabled by default since, about >2000 or 2001, I don't remember anymore, and I've never seen anyone >complain about increased delays. > >I don't think there should be any significant potential drawback *until* >the system is configured with a non-link-local address. There have been reports of problems with some Web browsers trying to use only the v6 address. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) -------------------------------------------------------------------- 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 Mar 11 12:46:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BKkK7f013394; Tue, 11 Mar 2003 12:46:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BKkJ8k013393; Tue, 11 Mar 2003 12:46:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BKkF7f013378 for ; Tue, 11 Mar 2003 12:46:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BKkNvx009807 for ; Tue, 11 Mar 2003 12:46:23 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11202 for ; Tue, 11 Mar 2003 12:46:17 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 20:46:14 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 20:46:13 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 20:46:13 Z Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 20:46:11 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5ED694FA4; Wed, 12 Mar 2003 05:45:32 +0900 (JST) To: "Steven M. Bellovin" Cc: Pekka Savola , Alain Durand , "Bound, Jim" , Sebastien Roy , Mika Liljeberg , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: smb's message of Tue, 11 Mar 2003 10:23:45 EST. <20030311152345.C83AB7B6C@berkshire.research.att.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dual stack & IPv6 on by default From: itojun@iijlab.net Date: Wed, 12 Mar 2003 05:45:32 +0900 Message-Id: <20030311204532.5ED694FA4@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >There have been reports of problems with some Web browsers trying to >use only the v6 address. this is due to the way mozilla is written. mozilla did: hp = gethostbyname2(host, AF_INET6); if (!hp) hp = gethostbyname(host); so mozilla tries to connect to IPv6/v4 dual stack destination, it would try to connect to IPv6 only. it has to be fixed by using getaddrinfo(3). itojun -------------------------------------------------------------------- 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 Mar 11 13:07:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BL7v7f014183; Tue, 11 Mar 2003 13:07:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BL7vl9014182; Tue, 11 Mar 2003 13:07:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BL7r7f014175 for ; Tue, 11 Mar 2003 13:07:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BL81vx016915 for ; Tue, 11 Mar 2003 13:08:01 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05500 for ; Tue, 11 Mar 2003 14:07:55 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:07:55 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:05:38 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:07:54 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:07:54 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0A837B31; Tue, 11 Mar 2003 16:07:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 16:07:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Tue, 11 Mar 2003 16:07:53 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB71@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLoD51nIEUQhOCAQG2vFCBI8FHdgwAAjIUQ From: "Bound, Jim" To: , "Steven M. Bellovin" Cc: "Pekka Savola" , "Alain Durand" , "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , , , X-OriginalArrivalTime: 11 Mar 2003 21:07:53.0992 (UTC) FILETIME=[484DF880:01C2E812] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2BL7s7f014176 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Mozilla is going to fix this. Part of the problem was we took so long getting rfc 2553 updated to new RFC (its in the RFC editor queue now) they used Richard Stevens old program model. This will be updated to getaddrinfo and I agree with Itojun. Now as usual we await release updates :--) We also updated the API after this code base that is must specify AI_MAPPED to get both v4 and v6. Regards, /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Tuesday, March 11, 2003 3:46 PM > To: Steven M. Bellovin > Cc: Pekka Savola; Alain Durand; Bound, Jim; Sebastien Roy; > Mika Liljeberg; Ronald van der Pol; v6ops@ops.ietf.org; > jim.Paugh@Sun.COM; ipng@sunroof.eng.sun.com > Subject: Re: dual stack & IPv6 on by default > > > >There have been reports of problems with some Web browsers trying to > >use only the v6 address. > > this is due to the way mozilla is written. > mozilla did: > hp = gethostbyname2(host, AF_INET6); > if (!hp) > hp = gethostbyname(host); > so mozilla tries to connect to IPv6/v4 dual stack > destination, it > would try to connect to IPv6 only. it has to be fixed by using > getaddrinfo(3). > > itojun > -------------------------------------------------------------------- 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 Mar 11 13:10:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BLAl7f014278; Tue, 11 Mar 2003 13:10:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BLAlIg014277; Tue, 11 Mar 2003 13:10:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BLAh7f014270 for ; Tue, 11 Mar 2003 13:10:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BLAoYt025290 for ; Tue, 11 Mar 2003 13:10:51 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07448 for ; Tue, 11 Mar 2003 14:10:45 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:10:44 Z Received: from mms01bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:10:44 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:10:44 Z Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:10:43 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5485C4FC1; Wed, 12 Mar 2003 06:10:42 +0900 (JST) To: "Bound, Jim" Cc: "Steven M. Bellovin" , "Pekka Savola" , "Alain Durand" , "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-reply-to: Jim.Bound's message of Tue, 11 Mar 2003 16:07:53 EST. <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB71@tayexc13.americas.cpqcorp.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dual stack & IPv6 on by default From: itojun@iijlab.net Date: Wed, 12 Mar 2003 06:10:42 +0900 Message-Id: <20030311211042.5485C4FC1@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Mozilla is going to fix this. Part of the problem was we took so long >getting rfc 2553 updated to new RFC (its in the RFC editor queue now) >they used Richard Stevens old program model. This will be updated to >getaddrinfo and I agree with Itojun. Now as usual we await release >updates :--) We also updated the API after this code base that is must >specify AI_MAPPED to get both v4 and v6. no need for that, you can use PF_UNSPEC in hints.ai_family to get both IPv4 address (as ai_family = AF_INET) and IPv6 address (as ai_family = AF_INET6) and socket(2) as appropriate. itojun -------------------------------------------------------------------- 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 Mar 11 13:56:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BLuF7f014926; Tue, 11 Mar 2003 13:56:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2BLuFGo014925; Tue, 11 Mar 2003 13:56:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2BLuB7f014918 for ; Tue, 11 Mar 2003 13:56:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2BLuJYt010628 for ; Tue, 11 Mar 2003 13:56:19 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06605 for ; Tue, 11 Mar 2003 14:56:13 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:56:13 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:53:56 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:56:12 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 11 Mar 2003 21:56:12 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13916; Tue, 11 Mar 2003 16:54:01 -0500 (EST) Message-Id: <200303112154.QAA13916@ietf.org> To: IETF-Announce:; Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: Advanced Sockets API for IPv6 to Informational Date: Tue, 11 Mar 2003 16:54:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Advanced Sockets API for IPv6' as an Informational RFC. This document is the product of the IP Version 6 Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. RFC Editor Note: The third reference: > [POSIX] IEEE Std. 1003.1-2001 Standard for Information > Technology -- Portable Operating System Interface > (POSIX) > > Open Group Technical Standard: Base Specifications, > Issue 6 December 2001 > > ISO 9945 (pending final approval by ISO) > > http://www.opengroup.org/austin > should be chnaged to: [3] IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX). Open Group Technical Standard: Base Specifications, Issue 6, December 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin -------------------------------------------------------------------- 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 Mar 11 23:01:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C7167f017115; Tue, 11 Mar 2003 23:01:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2C716SB017114; Tue, 11 Mar 2003 23:01:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C7137f017107 for ; Tue, 11 Mar 2003 23:01:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2C71Bvx010770 for ; Tue, 11 Mar 2003 23:01:11 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08115 for ; Tue, 11 Mar 2003 23:01:05 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:01:05 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:01:04 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:01:04 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:01:04 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2C70VY10723; Wed, 12 Mar 2003 09:00:31 +0200 Date: Wed, 12 Mar 2003 09:00:31 +0200 (EET) From: Pekka Savola To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] In-Reply-To: <20030311144318.GY8715@login.ecs.soton.ac.uk> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Mar 2003, Tim Chown wrote: > On Tue, Mar 11, 2003 at 04:39:22PM +0200, Pekka Savola wrote: > > > > But then again, the above case hasn't been mentioned in any analysis I > > recall (just made it up), so it's difficult to say. I certainly don't > > feel there are a lot of issues with security in RA-based DNS discovery. > > OK, so do you think it;s worth getting it tabled (late) in dnsext in San > Francisco (given they have no public agenda yet?) Sure, why not? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 11 23:06:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C76k7f017278; Tue, 11 Mar 2003 23:06:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2C76kQ4017277; Tue, 11 Mar 2003 23:06:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C76g7f017265 for ; Tue, 11 Mar 2003 23:06:42 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2C76oYt010984 for ; Tue, 11 Mar 2003 23:06:50 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16955 for ; Tue, 11 Mar 2003 23:06:44 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:06:43 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:04:26 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:06:43 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 07:06:42 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2C76aN10768; Wed, 12 Mar 2003 09:06:36 +0200 Date: Wed, 12 Mar 2003 09:06:35 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: john.loughney@nokia.com, , Subject: RE: draft-ietf-ipv6-node-requirements-03.txt In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB39@tayexc13.americas.cpqcorp.net> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 11 Mar 2003, Bound, Jim wrote: > In addition the Enterprise wireline networks and IT are not going to > give up stateful control with servers and NAS in their networks for a > long time with IPv6 is my intelligence from my work with users. Are servers and NAS configured with DHCPv4 today? Not that I know of, we certainly don't do it (even though we use DHCPv4 for most workstations). Of course, that's possible, e.g. by identifying MAC-address in the servers etc., but I'm not sure if all that many folks do it. Don't underestimate the power of an admin doing manual configuration. :-) So, my point is that there's a lot more to it than just "stateful" or "stateless". The critical point, IMO, is making the nodes able to easily configure other parameters they'd like, using DHCP-lite, or other mechanisms like that. Few people prefer to punch all of that in manually. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 12 00:19:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C8JQ7f017785; Wed, 12 Mar 2003 00:19:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2C8JQAh017784; Wed, 12 Mar 2003 00:19:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C8JM7f017777 for ; Wed, 12 Mar 2003 00:19:22 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2C8JUvx025176 for ; Wed, 12 Mar 2003 00:19:30 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19742 for ; Wed, 12 Mar 2003 00:19:24 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:19:23 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:19:23 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:19:23 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:19:22 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id B680C15210; Wed, 12 Mar 2003 17:20:23 +0900 (JST) Date: Wed, 12 Mar 2003 17:19:45 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t5el5h5u0g.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> <7t5el5h5u0g.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 08 Mar 2003 23:16:31 +0000, >>>>> Ole Troan said: >> Since this is a MAY, the delegating router (i.e. server) MAY NOT send >> a Reply message, which will cause a bad effect (that the invalid >> prefix is going to be used). For the case of address assignment, this >> should be a minor issue, because this situation only happens when none >> of the events to issue a Confirm happen but the upstream router has >> somehow been swapped. > Rebind is only done for 10 seconds (using Confirms timers), then the > client goes back to Solicit state. Ah, okay, I missed the point. Then I'm fine with the current specification. It would still be helpful to explicitly note that Rebind only continues for 10 seconds, though. >> It would also be helpful to describe how the requesting should react >> to this event. > requesting router should go to Solicit state. I think this will be > made clearer in modified base spec/new PD revision where we'll use > NotOnLink rather than lifetimes = 0. Hmm, opt-prefix-delegation-03 still says: Rebind message If the delegating router cannot find a binding (...) the delegating router MAY send a Reply message to the requesting router containing the IA_PD with the lifetimes of the prefixes in the IA_PD set to zero. or are you talking about a change in a future revision? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 12 00:21:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C8Ld7f017805; Wed, 12 Mar 2003 00:21:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2C8LdnV017804; Wed, 12 Mar 2003 00:21:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2C8LY7f017797 for ; Wed, 12 Mar 2003 00:21:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2C8Lgvx029516 for ; Wed, 12 Mar 2003 00:21:42 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24606 for ; Wed, 12 Mar 2003 01:21:37 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:21:36 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:21:36 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:21:36 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 08:21:35 Z Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 65C6615210; Wed, 12 Mar 2003 17:22:38 +0900 (JST) Date: Wed, 12 Mar 2003 17:22:00 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: Ralph Droms , dhcwg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: DHCPv6 clarification draft and PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) In-Reply-To: <7t58yvp5tht.fsf@mrwint.cisco.com> References: <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> <7t58yvp5tht.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 08 Mar 2003 23:27:42 +0000, >>>>> Ole Troan said: >> I know (and agree), but I'm saying the PD specification should be >> clear wherever a difference between address assignment and prefix >> delegation exist. We should be rather redundant than leave the >> difference ambiguous. At least please reconsider each issue in the >> interop draft and merge necessary changes from it. > agree. revision 3 of the PD draft should have most of the issues from > the interop document included. Okay, I'll check the changes in more detail. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 12 05:37:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2CDbG7f018876; Wed, 12 Mar 2003 05:37:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2CDbGBq018875; Wed, 12 Mar 2003 05:37:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2CDbB7f018868 for ; Wed, 12 Mar 2003 05:37:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2CDbHYt014236 for ; Wed, 12 Mar 2003 05:37:18 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08779 for ; Wed, 12 Mar 2003 06:37:11 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:37:10 Z Received: from mms11bms.mms.us.syntegra.com by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:34:52 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:37:10 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:37:09 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 171983C60; Wed, 12 Mar 2003 08:37:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Mar 2003 08:37:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Wed, 12 Mar 2003 08:37:08 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCBA2@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLoEt+uaTxhhfDDRI2L6Ra3gkFdFgAiY5Vg From: "Bound, Jim" To: Cc: "Steven M. Bellovin" , "Pekka Savola" , "Alain Durand" , "Sebastien Roy" , "Mika Liljeberg" , "Ronald van der Pol" , , , X-OriginalArrivalTime: 12 Mar 2003 13:37:08.0854 (UTC) FILETIME=[7A8F2960:01C2E89C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2CDbC7f018869 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes this is better approach. /jim > -----Original Message----- > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Tuesday, March 11, 2003 4:11 PM > To: Bound, Jim > Cc: Steven M. Bellovin; Pekka Savola; Alain Durand; Sebastien > Roy; Mika Liljeberg; Ronald van der Pol; v6ops@ops.ietf.org; > jim.Paugh@Sun.COM; ipng@sunroof.eng.sun.com > Subject: Re: dual stack & IPv6 on by default > > > >Mozilla is going to fix this. Part of the problem was we > took so long > >getting rfc 2553 updated to new RFC (its in the RFC editor queue now) > >they used Richard Stevens old program model. This will be > updated to > >getaddrinfo and I agree with Itojun. Now as usual we await release > >updates :--) We also updated the API after this code base > that is must > >specify AI_MAPPED to get both v4 and v6. > > no need for that, you can use PF_UNSPEC in > hints.ai_family to get both > IPv4 address (as ai_family = AF_INET) and IPv6 address > (as ai_family > = AF_INET6) and socket(2) as appropriate. > > itojun > > -------------------------------------------------------------------- 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 Mar 12 05:39:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2CDdb7f018907; Wed, 12 Mar 2003 05:39:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2CDdbDm018906; Wed, 12 Mar 2003 05:39:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2CDdX7f018899 for ; Wed, 12 Mar 2003 05:39:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2CDdevx027811 for ; Wed, 12 Mar 2003 05:39:40 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21876 for ; Wed, 12 Mar 2003 06:39:35 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:39:34 Z Received: from mms11bms.mms.us.syntegra.com by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:39:34 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:39:34 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 13:39:33 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6B8968ED; Wed, 12 Mar 2003 08:39:33 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Mar 2003 08:39:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Wed, 12 Mar 2003 08:39:32 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCBA3@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLoZe7mDJzonvIuR5ui+ENY/0aA/gANpEeA From: "Bound, Jim" To: "Pekka Savola" Cc: , , X-OriginalArrivalTime: 12 Mar 2003 13:39:33.0127 (UTC) FILETIME=[D08D7970:01C2E89C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2CDdX7f018900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Tue, 11 Mar 2003, Bound, Jim wrote: > > In addition the Enterprise wireline networks and IT are not > going to > > give up stateful control with servers and NAS in their > networks for a > > long time with IPv6 is my intelligence from my work with users. > > Are servers and NAS configured with DHCPv4 today? Sometimes. Point above was NAS and SErvers use DHCPv4 to give out the addreses and maintain that database. > > Not that I know of, we certainly don't do it (even though we > use DHCPv4 for most workstations). Of course, that's > possible, e.g. by identifying MAC-address in the servers > etc., but I'm not sure if all that many folks do it. > > Don't underestimate the power of an admin doing manual > configuration. :-) > > So, my point is that there's a lot more to it than just > "stateful" or "stateless". > > The critical point, IMO, is making the nodes able to easily > configure other parameters they'd like, using DHCP-lite, or > other mechanisms like that. Few people prefer to punch all > of that in manually. The 'O' Bit is supportive of SHOULD too. /jim > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > -------------------------------------------------------------------- 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 Mar 12 12:45:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2CKj37f003977; Wed, 12 Mar 2003 12:45:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2CKj3Uq003976; Wed, 12 Mar 2003 12:45:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2CKix7f003969 for ; Wed, 12 Mar 2003 12:44:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2CKj6vx019912 for ; Wed, 12 Mar 2003 12:45:06 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14575 for ; Wed, 12 Mar 2003 13:44:58 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 20:43:30 Z Received: from mms01bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 20:43:29 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 20:43:29 Z Received: from pguin2.txc.com (pguin2.txc.com [208.5.237.254]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 12 Mar 2003 20:43:29 Z Received: from txc.com ([172.17.0.226]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id h2CKhMs09838; Wed, 12 Mar 2003 15:43:23 -0500 Message-Id: <3E6F9C5E.5904DAD@txc.com> Date: Wed, 12 Mar 2003 15:45:18 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Brian E Carpenter , Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: trusting end-nodes to do the right thing [Re: IPv6 w.g. Last Callon "IPv6 Flow Label Specification"] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3E7247EC784CB15B8754E04C" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3E7247EC784CB15B8754E04C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pekka, Please see in line: Pekka Savola wrote: > > We may be treading into a very difficult situation (in some ways similar > to why MIPv6 got pushback from the IESG, IMO), and to be pre-emptive, I'd > really appreciate if folks would have a look at the particular issue (at > the end of the mail) and think whether it is a problem or not. > > On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > > The 3-tuple of the Flow Label and the Source and Destination Address > > > fields enables efficient IPv6 flow classification, where only IPv6 > > > main header fields in fixed positions are used. > > > > > > ==> this might require some extra analysis somewhere (not in that > > > particular place, I think). In particular, this seems to say that once > > > this is published people can happily move to using the three-tuple > > > classification. The reality is probably quite different, and one must > > > also consider the big portion of nodes which do not mark the flows. > > > > The goal of this document is not to describe use cases. It is > > to set the minimum conditions hosts and routers must meet. I do > > not believe we should add use cases to this document. > > I believe the original text does not give a realistic picture of the > situation. > > For the purpose of minimum conditions, the text could be removed > altogether, of course -- that would be fine by me. I could also live with > (by a thread :-) the current version, but I really believe it should be > changed slightly. > I would suggest we take your statement that "you could live with the current version". I do not think that what is to be said, can be said significantly better, than the way it is said in the draft, in plain, simple, accurate English. > > > To enable applications and transport protocols to define what packets > > > constitute a flow, the source node MUST provide means for the > > > applications and transport protocols to specify the Flow Label values > > > to be used with their flows. > > > > > > ==> this requirement seems unacceptable at the moment. This clearly > > > requires (at least) de-facto API so applications could set Flow Label > > > values -- and as such does not exist. If it did (and I believe there's > > > work in progress), there would *have to be* a normative reference to it). > > > So, clearly a MUST seems to a big no-no. > > > > But this is a statement about what hosts must do to make the flow label > > useful. > > No, that's not correct, or either of us is misunderstanding the paragraph > above (if so, a wording change is needed). > > The nodes (kernel, in particular) are able to mark flows by itself, > without any interaction from the applications -- so having apps have a > MUST possibility to influence the flow labeling is undoubtedly useful, but > certainly not something requiring MUST, considering the current situation. > In simplified translation, the text says that the IP layer is not the only layer selecting flow label values. This is the way it MUST be: in a node, which is sourcing labeled packets, the flow label value is in the same category with other fields of the IPv6 header: clients of the IP layer (layers above) MUST be able to set the value, if they need to. > Note: I'd argue for MUST myuself if we had had a standard (or even > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > year before this being sent to the IESG. > The (this) requirement is not conditional to the existence of an API, or an API function call mechanism. Rather the API, or the API function call, or the API functioFrom owner-ipng@sunroof.eng.sun.com Wed Mar 12 21:18:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2D5Ih7f016468; Wed, 12 Mar 2003 21:18:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2D5IgYJ016467; Wed, 12 Mar 2003 21:18:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2D5Ic7f016460 for ; Wed, 12 Mar 2003 21:18:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2D5Icvx025590 for ; Wed, 12 Mar 2003 21:18:38 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25780 for ; Wed, 12 Mar 2003 22:18:32 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 05:18:31 Z Received: from mms02bms.mms.us.syntegra.com by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 05:18:31 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 05:18:30 Z Received: from starfruit.itojun.org ([210.130.49.60] [210.130.49.60]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 05:18:20 Z Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B0E1B791; Thu, 13 Mar 2003 13:46:07 +0900 (JST) To: Erik Nordmark Cc: ettikan.kandasamy.karuppiah@intel.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, mrw@windriver.com In-reply-to: Erik.Nordmark's message of Wed, 12 Feb 2003 17:37:33 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt From: Jun-ichiro itojun Hagino Date: Thu, 13 Mar 2003 13:46:07 +0900 Message-Id: <20030313044607.B0E1B791@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry that i missed the i-d deadline for this. note that the document is in IESG queue for a lo---ng time. >RFC 3258 uses the term "shared-unicast address" for what you seem to be calling >"pseudo-anycast". I wonder if it makes sense using this existing term instead >of creating a new one. if "shared-unicast address" is more common, i'm happy to use that term. >RFC 3258 talks about an organization using anycast internally while speaking >BGP to the external world, yet in section 2.2 you bundle this with >draft-ietf-dnsop-ohta-shared-root-server-02.txt and seem to say that >they both cross AS boundaries. As I understand it the technical difference >between 3258 and shared-root-server is whether it is contained within one AS >or not. Thus it would make sense to make this more clear in the document. >Currently section 2.2 seems to only speak about the ohta approach, and >my understanding is that the RFC 3258 approach is more widely deployed for DNS. >I think RFC 3258's shared-unicast approach is quite useful given the >constraints it imposes on itself: > - used for DNS lookups i.e. short transactions > - that the DNS has a failure recovery mechanism (through multiple NS records > and multiple nameservers in resolv.conf) which provides failure recovery > even though the routes are not withdrawn when an instance of the > shared-unicast service dies. > >To make this more clear you can either remove the mention of BGP and >"distant domains" from section 2.2 or you can make it clear what the Hardie >and Ohta-san documents have in common and what is different (with the "distant >domains" being the difference). i'll update the draft to refer RFC3258 and make necessary adjustments. i'm not sure if i should keep references to mohta-san's draft. >I think it would be very useful to point out in section 3.3 that there >is nothing inherent in IPv6 that prevents the use of pseudo-anycast - >the issues listed in section 3.4 apply to both IPv4 and IPv6. >I don't think there is WG concensus to endorse such behavior for IPv6 >even through the scheme used in the Hardie and Ohta-san documents would work >just as well (or poorly) in IPv6 as in IPv4. i guess title of section 3 was vague - "current proposals" tries to mean "current proposals made for IPv6", like RFC2373 limitation for IPv6 anycast address assignment. therefore, 3.3 talks about restriction imposed by RFC2373, which is applicable to IPv6 only. i'll update title of section 3 to be more clear, and make sure to remove any IPv4 topic from section 3. >I don't understand what the last paragraph in section 4.1 is trying to >say. Clearly carrying /128 routes for anycast word-wide doesn't scale for >arbitrary use of anycast (but having explicit routes e.g. for DNS root servers >isn't an abitrary use since the set of addresses would be very limited). >Whether site-locals or globals are used it is required that the anycast >addresses aggregate into existing prefix routes at some scale. >But is the paragraph trying to say that this is some improvement that is >needed? (It is in a section about possible improvements.) >It can be read as this being something that needs to be fixed, but I think >it is just a fundamental constraint whether anycast addresses are assigned >to only routers or also to hosts. Thus the point seems to belong in section 1. the paragraph tries to say: - if we use predefined site-local anycast address, the propagation of host route (/128) would be limited within the site, therefore it may be permissible (depending on the routing table size of the site) - if we use predefined global anycast address, host route needs to be carried worldwide and we will see problems like you mentioned above. how should i word it for clarity? >Section 5.1 says: > Note that, however, bad guys can still inject fabricated results to the > client, even if the client checks the source address of the reply. The > check does not improve security of the exchange at all. > >This seems counter to the wisdom that lead to requiring the addresses >to match, yet you don't refute those arguments. > >I think in reality the (very spotty but existing) application of ingress >filtering in the 'net means that the DNS requirement on matching addresses >in requests and replies provide a non-zero security improvement. > >I think it is a bad idea to have an informational document like this >try to change the DNS protocol practise to not check the source address of >the reply. If you want to change this we need a standards track document. >Having this informational document discuss the issue of source address >checking is fine, but it isn't fine that it effectively removes it. then i would need to write up a separate dnsext document for the removal of the check. ok, i'll try to do that. >o For many of the existing protocols, we cannot perform sanity checks > using IP source address address. More specifically, for UDP DNS > replies against queries to anycast address, it is not recommended to > check source address, based on RFC2181 section 4.1. > >I don't see any text in section 4.1 in 2181 that recommends changing >anything on the client. In fact section 4 and 4.1 is how to make >servers work with clients that do verify the source address of the reply. >Thus I can't see how you come to this conclusion. quoting RFC2181: >> will be able to use it for further queries. Servers configured in >> such a way that not all their addresses are equally reachable from >> all potential clients need take particular care when responding to <--- >> queries sent to anycast, multicast, or similar, addresses. <--- from the above text, it is clear that client should/can not check the source address of the reply in the above case. >Section 7: > For secure anycast operation, we may need to enable security mechanisms > in other protocols. For example, if we were to inject /128 routes from > end hosts by using a routing protocol, we may need to configure the > routing protocol to exchange routes securely, to prevent malicious > parties from injecting bogus routes. > >"exchange routes securely" reads like securing the exchange of the routes >between the host and the router. That is useful but inadequate. The difficult >problem is how the router knows which host is *authorized* to inject >a route for which anycast address. Securing the communication between the host >and router doesn't solve the authorization problem. It would make sense to >point this out as an unsolved problem (short of manual configuration) in >the draft. routers will know that the host is authorized to inject a route to the routing system, by the fact that it knows the shared secret used by the routing protocol (if the route is advertised with proper authentication encapsulation/extension header, it is authorized). do i need to be more clear on such trivial thing? if so, how? itojun -------------------------------------------------------------------- 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 Mar 12 23:20:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2D7K57f016831; Wed, 12 Mar 2003 23:20:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2D7K5uO016830; Wed, 12 Mar 2003 23:20:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2D7K27f016823 for ; Wed, 12 Mar 2003 23:20:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2D7K1vx015566 for ; Wed, 12 Mar 2003 23:20:01 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16836 for ; Thu, 13 Mar 2003 00:19:50 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 07:19:46 Z Received: from mms02bms.mms.us.syntegra.com by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 07:19:46 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 07:19:46 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 07:19:45 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2D7JSk19928; Thu, 13 Mar 2003 09:19:28 +0200 Date: Thu, 13 Mar 2003 09:19:27 +0200 (EET) From: Pekka Savola To: Alex Conta cc: Brian E Carpenter , Bob Hinden & Margaret Wasserman , Subject: Re: trusting end-nodes to do the right thing [Re: IPv6 w.g. Last Callon "IPv6 Flow Label Specification"] In-Reply-To: <3E6F9C5E.5904DAD@txc.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Mar 2003, Alex Conta wrote: > > On Wed, 5 Mar 2003, Brian E Carpenter wrote: > > > > The 3-tuple of the Flow Label and the Source and Destination Address > > > > fields enables efficient IPv6 flow classification, where only IPv6 > > > > main header fields in fixed positions are used. > > > > > > > > ==> this might require some extra analysis somewhere (not in that > > > > particular place, I think). In particular, this seems to say that once > > > > this is published people can happily move to using the three-tuple > > > > classification. The reality is probably quite different, and one must > > > > also consider the big portion of nodes which do not mark the flows. > > > > > > The goal of this document is not to describe use cases. It is > > > to set the minimum conditions hosts and routers must meet. I do > > > not believe we should add use cases to this document. > > > > I believe the original text does not give a realistic picture of the > > situation. > > > > For the purpose of minimum conditions, the text could be removed > > altogether, of course -- that would be fine by me. I could also live with > > (by a thread :-) the current version, but I really believe it should be > > changed slightly. > > > > I would suggest we take your statement that "you could live with the > current version". > > I do not think that what is to be said, can be said significantly > better, than the way it is said in the draft, in plain, simple, accurate > English. Ok. > > > > To enable applications and transport protocols to define what packets > > > > constitute a flow, the source node MUST provide means for the > > > > applications and transport protocols to specify the Flow Label values > > > > to be used with their flows. > > > > > > > > ==> this requirement seems unacceptable at the moment. This clearly > > > > requires (at least) de-facto API so applications could set Flow Label > > > > values -- and as such does not exist. If it did (and I believe there's > > > > work in progress), there would *have to be* a normative reference to it). > > > > So, clearly a MUST seems to a big no-no. > > > > > > But this is a statement about what hosts must do to make the flow label > > > useful. > > > > No, that's not correct, or either of us is misunderstanding the paragraph > > above (if so, a wording change is needed). > > > > The nodes (kernel, in particular) are able to mark flows by itself, > > without any interaction from the applications -- so having apps have a > > MUST possibility to influence the flow labeling is undoubtedly useful, but > > certainly not something requiring MUST, considering the current situation. > > > > In simplified translation, the text says that the IP layer is not the > only layer selecting flow label values. This is the way it MUST be: in a > node, which is sourcing labeled packets, the flow label value is in the > same category with other fields of the IPv6 header: clients of the IP > layer (layers above) MUST be able to set the value, if they need to. ... > > Note: I'd argue for MUST myuself if we had had a standard (or even > > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > > year before this being sent to the IESG. > > > > The (this) requirement is not conditional to the existence of an API, or > an API function call mechanism. Rather the API, or the API function > call, or the API function call parameter, is a consequence of this > requirement, which is the way it should be. No, I have to disagree with this approach. In this case, making a normative reference to an API document (which would delay the publication of flow label specification until the API is published) would be OK, but I'm not sure that's what folks would want. For *applications* and application writers (which are also the customers of flow label spec here) requiring that implementations provide any programming interface at all, one specific to the implementation is the worst choice possible. So, if one would like to write portable applications, you'd have to use each implementation-specific programming interface for every implementation. That seems counter-productive and unacceptable, IMO -- but I'd like to hear what application writers would say about that. I agree with the need of a way to have applications to be able to influence the flow label, but a MUST would possibly lead to one of the below: 1) all implementations implementing different programming interfaces; a non-starter for applications 2) implementations not implementing all of the flow label spec, ie. just blatantly ignoring the MUST (compare with the temporary/public address knob in the default address selection, in RFC3484 sect 5r7 -- this was a bad last-minute compromise which nobody have implemented AFAIK) 3) implementations waiting for an API before implementing the flow label spec > > > If you want to standardize a socket API extension that's fine, > > > the Open Group exists for that. However, I believe a MUST is needed. > > > > A MUST without a means is bad practise, IMO. > > > > This sets the rule, from the protocol stack angle, for the flow label > related API, API function call, or API function call parameter(s). The > rule will bring the "means". I guess we disagree on the usability of the API for application writers if the API is not uniform enough. Personally, I view an implementation-specific API for something generic like this useless (as a programmer). > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > > is currently using or has recently used when creating new flows. Flow > > > > Label values previously used with a specific pair of source and > > > > destination addresses MUST NOT be assigned to new flows with the same > > > > address pair within 120 seconds of the termination of the previous > > > > flow. > > > > > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > > > value which was previously used, and send the packet, the operating system > > > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > > > s/reuse/unintentionally reuse/, or some other rewording? > > > > > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > > > we included an algorithm, but the WG wanted it removed, so we removed it. > > > > Yes, the stack can do it easily -- no doubt about that -- but it's > > *wrong*; this is connected to the security issue, below. > > > > There were people that requested this particular behavior. I wonder if they realized the implications. I'm sure that e.g. people focusing on the network part of the flow label would really appreciate having a flow labels guaranteed to be distinct, so their use in QoS and whatever would be a lot simplified, but that ignores the big picture at the expense of looking at only part of the solution space. > So, were you saying earlier that if the text in the draft > > ***MUST ensure that it does not reuse Flow Label values....*** > > were: > > ***MUST ensure that it does not unintentionally reuse Flow Label > values....*** > > it would be OK with you ? I find that acceptable. Extra text in security considerations would still be required, though (as noted later in my message). > > > > methods MUST meet the following basic requirements: > > > > > > > > ==> this and the following points seem a little oddly placed in this memo: > > > > they seem out-of-place, as the rest of the memo seems to concentrate on > > > > entirely different issues. Personally I view specifying how source nodes > > > > should label flows one thing, and the rest entirely another. But I can > > > > live with these, even though I think they're more fit to a non-standards > > > > track document. > > > > > > Then you don't want a change here? > > > > I can live without it -- waiting to hear others' opinions -- but I think > > the source node behaviour is entirely different issue from the network > > treatment. > > Here is another opinion. The two are the essential aspects of the flow > label mechanism: setting the flow label in nodes sourcing packets(1), > and processing flow labels in nodes receiving labeled packets (2) > [packet forwarding nodes]. Note that (2) also semantically includes the destination nodes, not just in-between routers, if you're not careful with the terminology. As I read it, you wrote that as a disagreement, but IMO that sounds very much like a partial agreement to me: that flow labeling consists of two different functions. These functions have entirely different requirements and considerations, but naturally, both are required to implement flow labeling. I was just arguing that "2" and "1+1" still makes "2", but "1+1" could be simpler for those that are only interested in the first or second "1", etc. > > > > 5.1 Theft and Denial of Service > > > > > > > > ==> this section mainly deals with issues relating to forging all of the > > > > source,destination,label three-tuple (exception is the last paragraph, > > > > which deals with a trusted-node-but-untrusted-user/application case), > > > > which protects mainly against a DoS attack (resource depletion). > > > > > > > > This seems to overlook the most important part: the typical model today is > > > > that operators perform differentiation of flows *themselves*: this > > > > document proposes to shift that, *over an administrative boundary*, to the > > > > source nodes, which suddenly become trusted to do the right thing. > > > > > > No, it adds the *labelling* of flows to the source, as a new capability. > > > > The labeling with current "service model" leads to differentiation. I'll > > try to reword it again below. If the "service model" would be such that > > the source node is *not* expected to label flows correctly, I'd certainly > > agree. > > From the point of view of the "operators model", servicing packets based > on packet classification, labeling flows is essentially not different > than setting other packet header fields, which are used for packet > classification, so I do not understand why you see a difference. There > is no intention in the draft to shift the current model to a different > one, to any "administrative body" on the source nodes. The spec very clearly states that flow labeling enables classification based on (src, dst, flow label). That is clearly different than (src, dst, protocol, srcport, dstport). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 13 06:39:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DEdc7f019933; Thu, 13 Mar 2003 06:39:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DEdcio019932; Thu, 13 Mar 2003 06:39:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DEdZ7f019925 for ; Thu, 13 Mar 2003 06:39:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DEdijO024142 for ; Thu, 13 Mar 2003 06:39:44 -0800 (PST) Received: from relFrom owner-ipng@sunroof.eng.sun.com Thu Mar 13 10:08:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DI8O7f024509; Thu, 13 Mar 2003 10:08:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DI8OOX024508; Thu, 13 Mar 2003 10:08:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DI8K7f024501 for ; Thu, 13 Mar 2003 10:08:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DI8UcU019816 for ; Thu, 13 Mar 2003 10:08:30 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14923 for ; Thu, 13 Mar 2003 11:08:24 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 18:08:18 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 18:08:18 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 18:08:17 Z Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 18:08:17 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DI8ASc003882; Thu, 13 Mar 2003 13:08:11 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20781; Thu, 13 Mar 2003 13:08:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030313130543.00b675f8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 13:08:10 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt) Cc: Ole Troan , dhcwg@ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: References: <7t5el5h5u0g.fsf@mrwint.cisco.com> <4.3.2.7.2.20030220132513.00ba9a40@funnel.cisco.com> <7t5r89tut8y.fsf@mrwint.cisco.com> <7t5el5h5u0g.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I guess the next rev of the draft should change the text to indicate the use of NotOnLink. - Ralph At 05:19 PM 3/12/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Sat, 08 Mar 2003 23:16:31 +0000, > >>>>> Ole Troan said: > >[snip] > >> It would also be helpful to describe how the requesting should react > >> to this event. > > > requesting router should go to Solicit state. I think this will be > > made clearer in modified base spec/new PD revision where we'll use > > NotOnLink rather than lifetimes = 0. > >Hmm, opt-prefix-delegation-03 still says: > > Rebind message If the delegating router cannot find a binding >(...) > the delegating router MAY > send a Reply message to the requesting router > containing the IA_PD with the lifetimes of the > prefixes in the IA_PD set to zero. > >or are you talking about a change in a future revision? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 13 11:09:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DJ9w7f027036; Thu, 13 Mar 2003 11:09:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DJ9wig027035; Thu, 13 Mar 2003 11:09:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DJ9s7f027028 for ; Thu, 13 Mar 2003 11:09:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DJA3jO008927 for ; Thu, 13 Mar 2003 11:10:03 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25376 for ; Thu, 13 Mar 2003 12:09:50 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:09:42 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:09:41 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:09:41 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:09:41 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DJ9SvD002255; Thu, 13 Mar 2003 14:09:28 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA26554; Thu, 13 Mar 2003 14:09:27 -0500 (EST) Message-Id: <4.3.2.7.2.20030313140410.051499b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 14:09:27 -0500 To: Pekka Savola From: Ralph Droms Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Cc: "Bound, Jim" , john.loughney@nokia.com, , In-Reply-To: References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB39@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:06 AM 3/12/2003 +0200, Pekka Savola wrote: >On Tue, 11 Mar 2003, Bound, Jim wrote: > > In addition the Enterprise wireline networks and IT are not going to > > give up stateful control with servers and NAS in their networks for a > > long time with IPv6 is my intelligence from my work with users. > >Are servers and NAS configured with DHCPv4 today? Yes. The home NAT/router in my basement acts as a DHCP client on the interface connected to the ISP and as a DHCP server on the interface to my home network. Your question does raise an interesting issue - where, in the IPv6 specifications, is the behavior of a router in response to received router advertisements specified? How does a router behave if it receives an RA with either or both of the 'M' and 'O' bits set? Note that the DHCPv6 doesn't include the infamous sentence: "DHCP is not intended for use in configuring routers." I certainly anticipate routers using DHCPv6 for obtaining DNS and similar configuration information, as well as prefix delegation... - Ralph >Not that I know of, we certainly don't do it (even though we use DHCPv4 >for most workstations). Of course, that's possible, e.g. by identifying >MAC-address in the servers etc., but I'm not sure if all that many folks >do it. > >Don't underestimate the power of an admin doing manual >configuration. :-) > >So, my point is that there's a lot more to it than just "stateful" or >"stateless". > >The critical point, IMO, is making the nodes able to easily configure >other parameters they'd like, using DHCP-lite, or other mechanisms like >that. Few people prefer to punch all of that in manually. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > >-------------------------------------------------------------------- >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 Thu Mar 13 11:24:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DJOj7f028243; Thu, 13 Mar 2003 11:24:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DJOig8028237; Thu, 13 Mar 2003 11:24:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DJOc7f028217 for ; Thu, 13 Mar 2003 11:24:38 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8+Sun/8.12.8) with SMTP id h2DJOlp2871880; Thu, 13 Mar 2003 11:24:47 -0800 (PST) Message-Id: <200303131924.h2DJOlp2871880@jurassic.eng.sun.com> Date: Thu, 13 Mar 2003 11:25:04 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: Draft on IPv6 source address selection socket API To: Alain.Durand@Sun.COM Cc: ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, Samita.Chakrabarti@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Gs4Ai/2LdseO5pr5SS+FDA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your comments. > My first comment is that an API in that space is badly needed, > so I fully support an effort to standardize such an API. > Yes, I agree. > My second comment is on the suggested API itself. > Some of the rules in the address selection RFC > are common sense, some are really 'suggested practices' > that make sense in common cases, but not in all. > So, I would like to see an API that enable > to change ALL the rules in the second category. > for example: prefer larger scope, prefer v4 over v6,.... > The draft lists whether PREFER_LARGEST_SCOPE and other flags would be considered in the 'Open Issues' section. Your points are valid. It may make sense to define a set of additional useful flags intially; working group input would be valuable in this case. > From your list of open question, I would like to see > a 'request foo' option too. An application may > say: 'request non IPv4-mapped', or reqest 'global'. > If such an address in not available at the time, > the syscall could return an error. > In the second bullet of 'Open Issues', it asks if we need to define "REQUIRE" flags in addition to "PREFER". I think you are asking the same. Currently "PREFER" means that the application sends its choice of PREFERENCE to the kernel, if kernel cannot provide that, the application gets to use the default system assigned values. > Another thing I would like to see would be some tie-breakers, > when a application could say: 'all things beeing equal, I rather like to > use x' Can you provide some concrete example and how this would be useful in applications ? Thanks, -Samita > Samita Chakrabarti wrote: > > >We have had discussion about requirement of having a socket-API > >on source address selection, in this alias. > > > >A draft has been submitted to address source address selection at > >the per-socket (and per apps) basis. Currently it discusses preferences > >of source address selection by the application for privacy addresses, > >mobileipv6 addresses and Cryptographically generated addresses. > >Thus the application can reverse the sense of default source address > >selection by using the proposed APIs. > > > > > >Please provide your comments/feedback on the alias and to the authors. > > > > > >We have listed some open issues in the draft as well to seek suggestions > >from the working group for further enhancement of the draft. > > > >The draft will be available in the draft directory shortly, however, I am > >including the text file here. > > > > > >Thanks, > >-Samita > > > > > >------------------------------------------------------------------------ > > > > > > > > > > > > > > > >INTERNET-DRAFT Erik Nordmark > >Expires: August, 2003 Samita Chakrabarti > > Sun Microsystems, Inc. > > Julien Laganier > > Sun Microsystems, Inc. > > LIP / ENS-Lyon > > February, 2003 > > > > IPv6 Socket API for source address selection > > > > > > > >Status of this Memo > > > > This document is an Internet-Draft and is subject to > > all provisions of Section 10 of RFC2026. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > This Internet Draft expires August, 2003. > > > >Copyright Notice > > > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > > > > > > > > > > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 1] > > > >INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > >Abstract > > > > The IPv6 default address selection document describes the rules for > > selecting default source address by the system and indicates that > > the applications should be able to reverse the sense of system > > preference of source address selection for that application through > > possible API extensions. However, no such socket APIs exist in the > > basic or advanced IPv6 socket API documents. Hence this document > > specifies socket level options to prefer a particular source > > address as per the choice of the applications. It also discusses > > implications on the name-to-address translation API that performs > > part of the default address selection. The socket APIs described in > > this document will be particularly useful for Mobile IPv6 enabled > > applications and other IPv6 applications which want to choose > > between temporary and public addresses, CGA (cryptographically > > generated addresses) and non-CGA addresses etc.. > > > > > > > > > >Table of Contents > > > > 1. Introduction ........................................... 3 > > > > 2. Example Usage .......................................... 4 > > > > 3. Changes to the Socket Interface ........................ 5 > > > > 4. Changes to the protocol-independent > > nodename translation ............................ 6 > > > > 5. IPv4-Mapped IPv6 Addresses .............................. 7 > > > > 6. Security Considerations ................................. 7 > > > > 7. Open Issues ............................................. 7 > > > > 8. References .............................................. 8 > > > > 9. Acknowledgements ........................................ 8 > > > > 10. Authors' Addresses ...................................... 9 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 2] > > > >INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > >1. Introduction > > > > This document defines socket extensions to support the non-default > > choice of source address by the applications. The IPv6 default > > address selection [1] document has specified the rules for system > > default source address selection for an outbound IPv6 packet. > > Privacy considerations [6] have introduced "public" and "temporary" > > addresses. IPv6 Mobility [3] introduces "home address" and "care- > > of-address" definitions in the mobile systems. Although it is > > desirable to have default algorithms for the system to choose the > > source address of the outgoing IPv6 packet, an application may want > > to reverse that rule for efficiency and other application specific > > reasons. Currently IPv6 socket API extensions does not provide a > > mechanism to choose a particular source address other than simple > > bind() operation. The bind() operation allows an application to > > specify a particular source address. Thus in order to use bind() > > the application itself must make sure that the source address is > > appropriate for the destination address (e.g., with respect to the > > interface used to send packets to the destination). The application > > also needs to make sure about the appropriate scope of source address > > with respect to the destination address and so on. The mechanism > > presented in this document allows the application to specify > > attributes of the source addresses it prefers while still having the > > system do the rest of the default address selection. > > > > A socket option has been deemed useful for this purpose, as it > > enables an application ability to make a choice of source address at > > per-socket basis as well as it can provide flexibility of enabling > > and disabling choice of source addresses in non-connected sockets. > > The socket option uses a set of flags for source address preferences. > > Since source address selection and destination address ordering need > > to be partially implemented in getaddrinfo() [2] the corresponding > > set of flags are also defined for that routine. > > > > Thus this document introduces different flags for source address > > selection that can be used by the applications for Mobility [3], > > Privacy Extension [6] and CGA [7] scenarios. In future, more flags > > can be added to designate a choice for a certain type of source > > address as the needs may arise. > > > > > > The approach in this document is to allow the application to specify > > preferences on source addresses and not to be able to specify hard > > requirements. Thus for instance an application can specify that it > > prefers temporary addresses but if no temporary addresses are > > available to the default address selection algorithm, a public > > address would be chosen instead. > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 3] > > > >INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > > > > Furthermore, the approach is to define two flags for each purpose, > > so that an application can specify either that it prefers 'X' or > > prefers 'not X', or it can choose not to set either of the flags > > relating to 'X' and leave it up to the system default, perhaps while > > specifing its preferences for some other attribute of the source > > addresses. > > > > > >2. Example Usages > > > > > > The examples of usages discussed here are limited to applications > > supporting Mobile IPv6, IPv6 Privacy Extensions and Cryptographically > > Generated Addresses. Address selection document [1] recommends that > > home addresses should be preferred over care-of-address when both are > > configured. However, a mobile node may want to prefer care-of-address > > as source address for DNS query in the foreign network as it normally > > means a shorter and local return path compared to the route via the > > mobile node's home-agent when the query contains home-address as > > source address. Another example is IKE application which requires > > care-of-address as its source address for the initial security > > association pair with Home Agent [3] while the mobile node boots up > > at the foreign network and wants to do the key exchange before a > > successful home-registration. Also a Mobile IPv6 aware application > > may want to toggle between home-address and care-of-address > > depending on its location and state of the application. It > > may also want to open different sockets and use home-address as > > source address for one socket and care-of-address for the others. > > > > In a non-mobile environment, similarly an application may prefer to > > use temporary address as source address for certain cases. > > By default, the source address selction rule selects "public" > > address when both are available. For example, an application > > supporting web browser and mail-server may want to use "temporary" > > address for the former and "public" address for the mail-server as a > > mail-server may require reverse path for DNS records for anti-spam > > rules. > > > > > > Similarly, a node may be configured to use the cryptographically > > genenerated addresses by default, but an application may prefer not > > to use it. For instance, fping, a debugging tool which tests > > basic reachability of multiple destinations by sending packets in > > parallel, may find that the cost and time incurred in proof-of- > > ownership by CGA verification is not justified. > > On the other hand, when a node is not configured for CGA as default, > > an application may prefer using CGA by setting the socket option. It > > may subsequently verify that it is truly bound to a CGA by first > > calling getsockname() and then recomputing the CGA using the public > > key of the node. > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 4] > > > >INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > >3. Changes to the Socket Interface > > > > IPv6 Basic API [2] defines socket options for IPv6. This document > > adds a new socket option at the IPPROTO_IPV6 level. This socket > > option is called IPV6_SRC_PREFERENCES. It can be used with > > setsockopt() and getsockopt() calls. This socket option takes a > > 32bit unsigned integer argument. The argument consists of a number > > of flags which indicate the choice of source address selection. > > > > The flags defined in this document are: > > > > IPV6_PREFER_SRC_HOME > > IPV6_PREFER_SRC_COA > > IPV6_PREFER_SRC_TMP > > IPV6_PREFER_SRC_PUBLIC > > IPV6_PREFER_SRC_CGA > > IPV6_PREFER_SRC_NONCGA > > > > > > The following example illustrates how it is used: > > > > uint32_t flags = IPV6_PREFER_SRC_COA; > > > > if (setsockopt(s, IPPROTO_IPV6, IPV6_SRC_PREFERENCES, > > (char *) &flags, sizeof (flags)) == -1) { > > perror("setsockopt IPV6_SRC_REFERENCES"); > > } > > > > > > When the IPV6_SRC_PREFERENCES is successfully set with setsockopt(), > > the option value given is used to specify source address for any > > connection initiation through the socket and all subsequent packets > > sent via that socket. If the option is not set, the system selects > > a default value. Setting conflicting flags at the same time results > > in the error EINVAL. > > > > It is recommended that the application does a getsockopt() prior > > calling to setsockopt() call so that it can save the existing > > source address preference value, in the cases when the application > > might need to restore the preferences. > > > > > > > > > > The constants mentioned in this section are defined in > > . > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 5] > > > >INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > > > >4. Changes to the protocol-independent nodename translation > > > > Section 8 of Default Address Selction [1] document indicates about > > possible implementation strategy for getaddrinfo() [2]. > > getaddrinfo() collects available source addresses from the network > > layer and then it sorts the list of source addresses as per source > > address selection rules. Thus if an application sets setsockopt() > > IPV6_SRC_PREFERENCES option to alter the default address selection > > rules , it must make sure that it calls getaddrinfo() with the > > corresponding flags specified in this section. This will ensure > > correct behavior of getaddrinfo() destination address selection > > based on the sorted list of source addresses as per the socket > > source address selection preferences. > > > > The following flags are added for the ai_flags in addrinfo data > > structure defined in Basic IPv6 Socket API Extension [2]. > > > > AI_PREFER_SRC_HOME > > AI_PREFER_SRC_COA > > AI_PREFER_SRC_TMP > > AI_PREFER_SRC_PUBLIC > > AI_PREFER_SRC_CGA > > AI_PREFER_SRC_NONCGA > > > > > > The above flags are ignored for the AF_INET address family. If a > > returned address is an IPv4 address (either as AF_INET6 when > > AI_V4MAPPED, or as AF_INET) then the source preference flags have > > no effect. > > > > If conflicting flags such as AI_PREFER_SRC_HOME and AI_PREFER_SRC_ > > COA are set, the getaddrinfo() fails with an error EAI_BADFLAGS[2]. > > > > Some valid sequences of flags would be: > > > > AI_PREFER_SRC_HOME | AI_PREFER_SRC_PUBLIC > > AI_PREFER_SRC_COA | AI_PREFER_SRC_PUBLIC > > AI_PREFER_SRC_HOME | AI_PREFER_SRC_CGA > > AI_PREFER_SRC_HOME | AI_PREFER_SRC_NONCGA > > AI_PREFER_SRC_COA | AI_PREFER_SRC_CGA > > AI_PREFER_SRC_COA | AI_PREFER_SRC_NONCGA > > > > > > > > All the constants mentioned in this section for ai_flags are defined > > in . > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 6] > > > >INTERNET DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > >5. IPv4-Mapped IPv6 Addresses > > > > IPv4-Mapped IPv6 addresses are not supported for setting preference > > on home, care-of-address, CGA, non-CGA, public or privacy auto- > > configured addresses as source addresses. Because they are all pure > > IPv6 addresses. > > > > > >6. Security Considerations > > > > This document conforms to the same security implications as specified > > in IPv6 Basic Socket API [2] document. It is also recommended that > > the applications set IPV6_V6ONLY IP level socket option to permit > > the nodes to not process IPv4 packets as IPv4 Mapped addresses. > > Allowing applications to specify a preference for temporary > > addresses provides per-application (and per-socket) ability to use > > the privacy benefits of the temporary addresses. > > > > > > > >7. Open Issues > > > > - Are there more flags we should define at this point in time? > > For instance, PREFER_LARGEST_SCOPE? > > > > - Is there a need for REQUIRE flags in addition to or instead of the > > PREFER flags? Note that in general it isn't possible to verify > > that a requirement can be satisfied until sendto() or connect() > > (when the destination address is known) thus this would result > > in late errors being reported to the application. > > > > - Is there a need for "validation" functions to go with these > > preferences such as functions that check whether an address is > > a temporary address? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 7] > > > >INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > >8. References > > > >Normative references: > > > >[1] Richard Draves, "Default Address Selection for IPv6", > > draft-ietf-ipv6-default-addr-select-09.txt, August 6, 2002. > > > >[2] R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens, > > "Basic Socket Interface Extensions for IPv6", > > draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002. > > > >Informative references: > > > >[3] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6" > > draft-ietf-mobileip-ipv6-20.txt, January, 2003. > > > >[4] Deering, S., Hinden, R., "Internet Protocol, Version 6 > > (IPv6), Specification", RFC 2460, Dec. 1998. > > > >[5] Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced > > Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt > > April 19, 2002. > > > >[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless > > Address Autoconfiguration in IPv6", RFC 3041, January 2001. > > > >[7] Montenegro, G. and C. Castelluccia, "Statistically Unique and > > Cryptographically Verifiable (SUCV) Identifiers and Addresses.", > > NDSS 2002, February 2002. > > > >[8] Castelluccia, C. and G. Montenegro, "Securing Group Management > > in IPv6 with Cryptographically Generated Addresses", > > draft-irtf-gsec-sgmv6-01 (work in progress), July 2002. > > > > > > > >9. Acknowledgements > > > > The authors like to thank members of mobile-ip and ipv6 working > > groups for useful discussion on this topic. Richard Draves and > > Dave Thaler suggested that getaddrinfo also needs to be considered > > along with the new socket option. Gabriel Montenegro suggested that > > CGAs may also be considered in this document. Thanks to Alain Durand, > > Renee Danson, Alper Yegin and Francis Dupont for useful discussions. > > > > > > > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 8] > > > >INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 > > > > > > > >10. Authors' Addresses > > > > > > Erik Nordmark > > Sun Microsystems Laboratories, Europe > > 180 Avenue de l'Europe > > 38334 Saint Ismier, France > > Email: Erik.Nordmark@sun.com > > > > > > > > Samita Chakrabarti > > Sun Microsystems, Inc. > > 4150 Network Circle > > Santa Clara, CA 95054, USA > > Email: samita.chakrabarti@Sun.com > > > > > > > > Julien Laganier > > Sun Microsystems Laboratories, Europe > > 180 Avenue de l'Europe > > 38334 Saint Ismier, France > > Email: Julien.Laganier@Sun.COM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 9] > > > > > > > > > -------------------------------------------------------------------- > 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 Thu Mar 13 11:33:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DJXL7f029446; Thu, 13 Mar 2003 11:33:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DJXLk0029445; Thu, 13 Mar 2003 11:33:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DJXG7f029429 for ; Thu, 13 Mar 2003 11:33:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DJXOcU002732 for ; Thu, 13 Mar 2003 11:33:24 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20104 for ; Thu, 13 Mar 2003 12:33:19 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:33:18 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:33:18 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:33:18 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 19:33:17 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2DJW4J24348; Thu, 13 Mar 2003 21:32:04 +0200 Date: Thu, 13 Mar 2003 21:32:04 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: "Bound, Jim" , , , Subject: RE: draft-ietf-ipv6-node-requirements-03.txt In-Reply-To: <4.3.2.7.2.20030313140410.051499b8@funnel.cisco.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Mar 2003, Ralph Droms wrote: > At 09:06 AM 3/12/2003 +0200, Pekka Savola wrote: > >On Tue, 11 Mar 2003, Bound, Jim wrote: > > > In addition the Enterprise wireline networks and IT are not going to > > > give up stateful control with servers and NAS in their networks for a > > > long time with IPv6 is my intelligence from my work with users. > > > >Are servers and NAS configured with DHCPv4 today? > > Yes. The home NAT/router in my basement acts as a DHCP client > on the interface connected to the ISP and as a DHCP server on > the interface to my home network. That's not what I meant at all, the scope was "enterprise"; I acknowledge your "unmanaged" case. > Your question does raise an interesting issue - where, in the IPv6 > specifications, is the behavior of a router in response to received > router advertisements specified? How does a router behave if > it receives an RA with either or both of the 'M' and 'O' bits > set? RFC2461 6.2.7 gives some insight: nothing is done, based on the current specification (but doing something is not explicitly forbidden either). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 13 12:11:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DKBE7f000951; Thu, 13 Mar 2003 12:11:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DKBDRB000950; Thu, 13 Mar 2003 12:11:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DKBA7f000939 for ; Thu, 13 Mar 2003 12:11:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DKBJcU019384 for ; Thu, 13 Mar 2003 12:11:19 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21057 for ; Thu, 13 Mar 2003 13:11:13 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 20:11:12 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 20:11:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 20:11:12 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 20:11:11 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2DKBAf24625; Thu, 13 Mar 2003 22:11:10 +0200 Date: Thu, 13 Mar 2003 22:11:10 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: Brian E Carpenter , Alex Conta , Bob Hinden & Margaret Wasserman Subject: flow label -05 sec cons modification text In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Following up from the last call and the issues I raised, I'll try to propose something to start with to make the security considerations more in line with certain imporant issues. Note: I'm assuming that the sentence: A source node MUST ensure that it does not reuse Flow Label values it is currently using or has recently used when creating new flows. will be changed, at least to "unintentionally reuse". Now, to the security considerations. 5.1 Theft and Denial of Service The goal of the Flow Label is to allow different levels of service to be provided for traffic streams on a common network infrastructure. A variety of techniques may be used to achieve this, but the end result will be that some packets receive different (e.g., better or worse) service than others. The mapping of network traffic to the flow- specific treatment is triggered by the IP addresses and Flow Label value of the IPv6 header, and hence an adversary may be able to obtain better service by modifying the IPv6 header or by injecting packets with false addresses and labels. Taken to its limits, such ^^^ ==> false addresses _or_ labels. theft-of-service becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to forward it and other traffic streams. ==> after this, add a new paragraph: Note that there is no guarantee that flow labels used in a node are not used in any manner the node wants to, even reusing flow labels. This is a feature: as nodes are typically untrusted, it cannot be assumed that they would in fact implement or adhere to any restrictions if such would be set -- and therefore any assumptions made by the network on nodes' behaviour should be very limited except in cases where the nodes are explicitly trusted. ==> and after the "Since flows.." paragraph, add paragraphs: There are two issues with different properties: spoofing of only Flow Label, and spoofing of the whole 3-tuple, including Source and Destination Address. The former can be done inside a node which is using the correct source address. Being able to spoof Flow Label typically requires being in position to also forge an address -- but in many cases, spoofing the address may not be the interesting, especially if the spoofer's goal is theft of service, not denial of service. The latter can be done by a host which is not subject to ingress filtering [INGR] or an intermediate router. Due to its properties, such is typically useful only for denial of service. ==> TODO: consider whether changes are needed (on ingress filtering) in the second-last paragraph. Perhaps this should get one started. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 13 12:46:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DKkW7f001703; Thu, 13 Mar 2003 12:46:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DKkVFV001702; Thu, 13 Mar 2003 12:46:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DKkR7f001692 for ; Thu, 13 Mar 2003 12:46:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DKkajO005003 for ; Thu, 13 Mar 2003 12:46:36 -0800 (PST) Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24508 for ; Thu, 13 Mar 2003 13:46:31 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBP00JQEGDITZ@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 13:46:31 -0700 (MST) Received: from sun.com ([129.146.15.17]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBP00GY7GDBX4@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 13:46:24 -0700 (MST) Date: Thu, 13 Mar 2003 12:48:34 -0800 From: Alain Durand Subject: Re: Draft on IPv6 source address selection socket API To: Samita Chakrabarti Cc: ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM Message-id: <3E70EEA2.5030802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <200303131924.h2DJOlp2871880@jurassic.eng.sun.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Samita Chakrabarti wrote: > > >>Another thing I would like to see would be some tie-breakers, >>when a application could say: 'all things beeing equal, I rather like to >>use x' >> >> > >Can you provide some concrete example and how this would be >useful in applications ? > A node with 2 interfaces, configured with global addresses. The 2 interfaces have different properties (fast/slow, free/expensive,...) and the apps knows about that. The App would like to say something like "All things equal, prefer interface X". - Alain. -------------------------------------------------------------------- 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 Mar 13 13:15:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DLFj7f003171; Thu, 13 Mar 2003 13:15:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DLFjdF003170; Thu, 13 Mar 2003 13:15:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DLFf7f003163 for ; Thu, 13 Mar 2003 13:15:41 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DLFpjO015934 for ; Thu, 13 Mar 2003 13:15:51 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20405 for ; Thu, 13 Mar 2003 13:15:45 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:15:44 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:15:42 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:15:42 Z Received: from pguin2.txc.com (pguin2.txc.com [208.5.237.254]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:15:42 Z Received: from txc.com ([172.17.0.226]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id h2DLFWs28242; Thu, 13 Mar 2003 16:15:32 -0500 Message-Id: <3E70F569.5AEB1FAB@txc.com> Date: Thu, 13 Mar 2003 16:17:29 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Brian E Carpenter , Bob Hinden & Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: trusting end-nodes to do the right thing [Re: IPv6 w.g. LastCallon "IPv6 Flow Label Specification"] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAD6FB48E50BDA2F1631F2B17" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msAD6FB48E50BDA2F1631F2B17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pekka, Please see in line: Pekka Savola wrote: > > On Wed, 12 Mar 2003, Alex Conta wrote: > [....] > > > > > > To enable applications and transport protocols to define what packets > > > > > constitute a flow, the source node MUST provide means for the > > > > > applications and transport protocols to specify the Flow Label values > > > > > to be used with their flows. > > > > > > > > > > ==> this requirement seems unacceptable at the moment. This clearly > > > > > requires (at least) de-facto API so applications could set Flow Label > > > > > values -- and as such does not exist. If it did (and I believe there's > > > > > work in progress), there would *have to be* a normative reference to it). > > > > > So, clearly a MUST seems to a big no-no. > > > > > > > > But this is a statement about what hosts must do to make the flow label > > > > useful. > > > > > > No, that's not correct, or either of us is misunderstanding the paragraph > > > above (if so, a wording change is needed). > > > > > > The nodes (kernel, in particular) are able to mark flows by itself, > > > without any interaction from the applications -- so having apps have a > > > MUST possibility to influence the flow labeling is undoubtedly useful, but > > > certainly not something requiring MUST, considering the current situation. > > > > > > > In simplified translation, the text says that the IP layer is not the > > only layer selecting flow label values. This is the way it MUST be: in a > > node, which is sourcing labeled packets, the flow label value is in the > > same category with other fields of the IPv6 header: clients of the IP > > layer (layers above) MUST be able to set the value, if they need to. > > ... > > > > Note: I'd argue for MUST myuself if we had had a standard (or even > > > de-facto standard!) mechanism specified (and hopefully implemented) for 1 > > > year before this being sent to the IESG. > > > > > > > The (this) requirement is not conditional to the existence of an API, or > > an API function call mechanism. Rather the API, or the API function > > call, or the API function call parameter, is a consequence of this > > requirement, which is the way it should be. > > No, I have to disagree with this approach. In this case, making a > normative reference to an API document (which would delay the publication > of flow label specification until the API is published) would be OK, but > I'm not sure that's what folks would want. > I think this was never intended: it is not a normative reference to an API document. It is simply a requirement for implementations. > For *applications* and application writers (which are also the customers > of flow label spec here) requiring that implementations provide any > programming interface at all, one specific to the implementation is the > worst choice possible. So, if one would like to write portable > applications, you'd have to use each implementation-specific programming > interface for every implementation. > The mechanism, whatever it is, a standard or proprietary API, or one function call of an API, or one or more parameters of an existent function call, or anything else, are all completely independent of this flow label specification. Please remember: publishing IPv6 specs as proposed standard (RFC), was never dependent on publishing or referencing an API. > That seems counter-productive and unacceptable, IMO -- but I'd like to > hear what application writers would say about that. I agree with the need > of a way to have applications to be able to influence the flow label, but > a MUST would possibly lead to one of the below: > > 1) all implementations implementing different programming interfaces; a > non-starter for applications > I think this is orthogonal to the flow label specification. > 2) implementations not implementing all of the flow label spec, ie. just > blatantly ignoring the MUST (compare with the temporary/public address > knob in the default address selection, in RFC3484 sect 5r7 -- this was a > bad last-minute compromise which nobody have implemented AFAIK) > It is a fact of life to have non-fully compliant implementations. That is orthogonal to the progress of a specification to proposed standard. > 3) implementations waiting for an API before implementing the flow label > spec > > > > > If you want to standardize a socket API extension that's fine, > > > > the Open Group exists for that. However, I believe a MUST is needed. > > > > > > A MUST without a means is bad practise, IMO. > > > > > > > This sets the rule, from the protocol stack angle, for the flow label > > related API, API function call, or API function call parameter(s). The > > rule will bring the "means". > > I guess we disagree on the usability of the API for application writers if > the API is not uniform enough. Personally, I view an > implementation-specific API for something generic like this useless (as a > programmer). Even if we do not go any further on this, I think we reached an area which is way outside the scope of the flow label specification. I may agree with you close to 100% on what you say right above, but only as part of a completely different topic, which is not this flow label specification, it is not this last call. > > > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > > > is currently using or has recently used when creating new flows. Flow > > > > > Label values previously used with a specific pair of source and > > > > > destination addresses MUST NOT be assigned to new flows with the same > > > > > address pair within 120 seconds of the termination of the previous > > > > > flow. > > > > > > > > > > ==> so, if I make create a raw socket, manually fiddle in the flow label > > > > > value which was previously used, and send the packet, the operating system > > > > > kernel should hijack it and prevent it from going out? Get real. Perhaps > > > > > s/reuse/unintentionally reuse/, or some other rewording? > > > > > > > > Yes, the stack is supposed to do that. It's not hard. In an earlier version > > > > we included an algorithm, but the WG wanted it removed, so we removed it. > > > > > > Yes, the stack can do it easily -- no doubt about that -- but it's > > > *wrong*; this is connected to the security issue, below. > > > > > > > There were people that requested this particular behavior. > > I wonder if they realized the implications. I'm sure that e.g. people > focusing on the network part of the flow label would really appreciate > having a flow labels guaranteed to be distinct, so their use in QoS and > whatever would be a lot simplified, but that ignores the big picture at > the expense of looking at only part of the solution space. > I think they did. Even though it is succinct, the specification defines, or mentions a number of mechanisms pertinent to a very diverse set of views, and uses. Personally, I favor some over the others, but after thinking, and understanding, I agreed that all can work. This was essential for being part of the current consensus, which took a long time, and a lot of work, from the WG, the authors, the WG chairs, and the area directors. > > So, were you saying earlier that if the text in the draft > > > > ***MUST ensure that it does not reuse Flow Label values....*** > > > > were: > > > > ***MUST ensure that it does not unintentionally reuse Flow Label > > values....*** > > > > it would be OK with you ? > > I find that acceptable. Extra text in security considerations would still > be required, though (as noted later in my message). > Let's hold on to this (including the word "unintentionally") for a moment. >[...] > > Here is another opinion. The two are the essential aspects of the flow > > label mechanism: setting the flow label in nodes sourcing packets(1), > > and processing flow labels in nodes receiving labeled packets (2) > > [packet forwarding nodes]. > > [...] > > As I read it, you wrote that as a disagreement, but IMO that sounds very > much like a partial agreement to me: that flow labeling consists of two > different functions. > Indeed, there is partial agreement. And there would be full agreement, if you looked at that as two functions, or rather two components of one mechanism. > These functions have entirely different requirements and considerations, > but naturally, both are required to implement flow labeling. > > I was just arguing that "2" and "1+1" still makes "2", but "1+1" could be > simpler for those that are only interested in the first or second "1", > etc. > Indeed, so we agree, as I expected above. > > > > > 5.1 Theft and Denial of Service > > > > > > > > > > ==> this section mainly deals with issues relating to forging all of the > > > > > source,destination,label three-tuple (exception is the last paragraph, > > > > > which deals with a trusted-node-but-untrusted-user/application case), > > > > > which protects mainly against a DoS attack (resource depletion). > > > > > > > > > > This seems to overlook the most important part: the typical model today is > > > > > that operators perform differentiation of flows *themselves*: this > > > > > document proposes to shift that, *over an administrative boundary*, to the > > > > > source nodes, which suddenly become trusted to do the right thing. > > > > > > > > No, it adds the *labelling* of flows to the source, as a new capability. > > > > > > The labeling with current "service model" leads to differentiation. I'll > > > try to reword it again below. If the "service model" would be such that > > > the source node is *not* expected to label flows correctly, I'd certainly > > > agree. > > > > From the point of view of the "operators model", servicing packets based > > on packet classification, labeling flows is essentially not different > > than setting other packet header fields, which are used for packet > > classification, so I do not understand why you see a difference. There > > is no intention in the draft to shift the current model to a different > > one, to any "administrative body" on the source nodes. > > The spec very clearly states that flow labeling enables classification > based on (src, dst, flow label). That is clearly different than (src, > dst, protocol, srcport, dstport). > You're pointing now to a difference in the placement of the fields in the headers, which I think is orthogonal to the difference you were pointing at before, to which I responded that there is no difference. Earlier, I think you were trying to say that without flow label, there is a certain model, which changes with the use of the flow label. Essentially, I responded that it is not the case, the model does not change: the model of trusting/doubting a flow label is not different from the model of trusting/doubting a pair of ports and a protocol number: they're all set by the source node of the packets, and are part of some classifiers set with some direct/indirect knowledge/agreement from network infrastructure operators. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings Regards, Alex Conta --------------msAD6FB48E50BDA2F1631F2B17 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhAwgIjt1LtpV2AM64D0R8bCMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkyMDAwMDAw MFoXDTAzMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFIjccjs9g z0DiQcpTsg+mbY5L+R2YaTNN6k2fRGSLMLitaA2YwdeN3goXG45bXCP8DldBS38EWHFT2/5Q cy9HnNQaS1GnG2xzngdev5HpVm/oAy1M9YPt96Zp2W5MKGIb87vxyXvb1KqRMA9paf/6xZ2C B4tH127oHyF1xT4k8wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBUOS83AALNc8pTZDApKndtQBiFQLPTu5ZL pE1TDsyd4y75K3gXUvqlprCFY8HgKwodqs9wTltqYRlvhZVlMXu1y0g8Z3MJ9KSddePYuuli jop+PplaAHS7DHXDJNNQt+n2i2K4j4uJFokE2JnvaEyBEHjtTmIt+JjS2Dygm57mwzCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDCAiO3Uu2lXYAzrgPRHxsIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTMyMTE3MzFaMCMGCSqGSIb3DQEJ BDEWBBRgp+jckJLITAyRL8QAztZM1747tzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgCXzDwPVM8u/DDIj3QxRe0qqYUTWOdv3zMXf6Dbdkk5vtQdV PedTFzk4hUff3XkS1TJqWRuXMWx6PQu/XB/EvHJQmBlnSmlSiJJspl76R8rSGVO1TCcBhOfQ uY2ZDwigZyZ7f6B89/zqlxbYI56y1VGSlbws59N+hPmGmc/jL9yL --------------msAD6FB48E50BDA2F1631F2B17-- -------------------------------------------------------------------- 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 Mar 13 13:43:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DLhR7f003525; Thu, 13 Mar 2003 13:43:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DLhR2i003524; Thu, 13 Mar 2003 13:43:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DLhO7f003517 for ; Thu, 13 Mar 2003 13:43:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DLhXcU004007 for ; Thu, 13 Mar 2003 13:43:33 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17672 for ; Thu, 13 Mar 2003 14:43:27 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:43:24 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:43:23 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:43:23 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:43:23 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2DLhHY25268; Thu, 13 Mar 2003 23:43:17 +0200 Date: Thu, 13 Mar 2003 23:43:17 +0200 (EET) From: Pekka Savola To: Alex Conta cc: Brian E Carpenter , Bob Hinden & Margaret Wasserman , Subject: Re: trusting end-nodes to do the right thing [Re: IPv6 w.g. LastCallon "IPv6 Flow Label Specification"] In-Reply-To: <3E70F569.5AEB1FAB@txc.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 13 Mar 2003, Alex Conta wrote: > Please remember: publishing IPv6 specs as proposed > standard (RFC), was never dependent on publishing or referencing an API. Then again, not all that may IPv6 specs state that implementation MUST provide applications with a way to set "foo". > > 2) implementations not implementing all of the flow label spec, ie. just > > blatantly ignoring the MUST (compare with the temporary/public address > > knob in the default address selection, in RFC3484 sect 5r7 -- this was a > > bad last-minute compromise which nobody have implemented AFAIK) > > > > It is a fact of life to have non-fully compliant implementations. > That is orthogonal to the progress of a specification to proposed > standard. Depends on what you want. I'd prefer working, useful specifications which do not have requirements which are not met. > > I wonder if they realized the implications. I'm sure that e.g. people > > focusing on the network part of the flow label would really appreciate > > having a flow labels guaranteed to be distinct, so their use in QoS and > > whatever would be a lot simplified, but that ignores the big picture at > > the expense of looking at only part of the solution space. > > > > I think they did. Even though it is succinct, the specification defines, > or mentions a number of mechanisms pertinent to a very diverse set of > views, and uses. Personally, I favor some over the others, but after > thinking, and understanding, I agreed that all can work. This was > essential for being part of the current consensus, which took a long > time, and a lot of work, from the WG, the authors, the WG chairs, and > the area directors. Consensus is not useful unless the result is useful. > > The spec very clearly states that flow labeling enables classification > > based on (src, dst, flow label). That is clearly different than (src, > > dst, protocol, srcport, dstport). > > > > You're pointing now to a difference in the placement of the fields in > the headers, which I think is orthogonal to the difference you were > pointing at before, to which I responded that there is no difference. No, I'm not interested in the placement -- I'm concerned about the data available to the network operator, and the assumptions the spec will give him on its applicability. > Earlier, I think you were trying to say that without flow label, there > is a certain model, which changes with the use of the flow label. That's correct. > Essentially, I responded that it is not the case, the model does not > change: the model of trusting/doubting a flow label is not different > from the model of trusting/doubting a pair of ports and a protocol > number: they're all set by the source node of the packets, and are part > of some classifiers set with some direct/indirect knowledge/agreement > from network infrastructure operators. If you believe adding the flow label in the mix does not change the model, I'd maybe call it naivete. The question is how much (and how) it's changed. But perhaps it would be better to have a look at some of the security considerations text I proposed on the list a few hours ago, and if you disagree, try to describe how you see the the model between the network and source nodes so we could understand the views better. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 13 13:46:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DLkH7f003605; Thu, 13 Mar 2003 13:46:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2DLkH1g003604; Thu, 13 Mar 2003 13:46:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2DLkD7f003594 for ; Thu, 13 Mar 2003 13:46:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2DLkMcU005287 for ; Thu, 13 Mar 2003 13:46:22 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05742 for ; Thu, 13 Mar 2003 14:46:16 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:46:15 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:46:15 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:46:15 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 13 Mar 2003 21:46:14 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2DLkYwY030007; Thu, 13 Mar 2003 23:46:35 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2DLkVnS030004; Thu, 13 Mar 2003 23:46:31 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: draft-ietf-ipv6-node-requirements-03.txt From: Mika Liljeberg To: Ralph Droms Cc: Pekka Savola , "Bound, Jim" , john.loughney@nokia.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20030313140410.051499b8@funnel.cisco.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB39@tayexc13.americas.cpqcorp.net> <4.3.2.7.2.20030313140410.051499b8@funnel.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047591991.18624.126.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Mar 2003 23:46:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-03-13 at 21:09, Ralph Droms wrote: > Your question does raise an interesting issue - where, in the IPv6 > specifications, is the behavior of a router in response to received > router advertisements specified? How does a router behave if > it receives an RA with either or both of the 'M' and 'O' bits > set? RFC2462 states several times that routers are not expected to process router advertisements. MikaL -------------------------------------------------------------------- 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 Mar 13 16:03:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2E0327f008031; Thu, 13 Mar 2003 16:03:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2E032Om008030; Thu, 13 Mar 2003 16:03:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2E02w7f008023 for ; Thu, 13 Mar 2003 16:02:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2E037cU025719 for ; Thu, 13 Mar 2003 16:03:07 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15701 for ; Thu, 13 Mar 2003 17:03:01 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 00:03:00 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 00:02:47 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 00:02:47 Z Received: from starfruit.itojun.org ([210.130.43.180] [210.130.43.180]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 00:02:46 Z Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 33536791; Fri, 14 Mar 2003 09:01:54 +0900 (JST) To: Ralph Droms Cc: ipng@sunroof.eng.sun.com In-reply-to: rdroms's message of Thu, 13 Mar 2003 14:09:27 EST. <4.3.2.7.2.20030313140410.051499b8@funnel.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ietf-ipv6-node-requirements-03.txt From: Jun-ichiro itojun Hagino Date: Fri, 14 Mar 2003 09:01:54 +0900 Message-Id: <20030314000154.33536791@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Are servers and NAS configured with DHCPv4 today? >Yes. The home NAT/router in my basement acts as a DHCP client >on the interface connected to the ISP and as a DHCP server on >the interface to my home network. i don't usually call a home router "NAS". NAS usually refers to router equipment on the ISP side. itojun -------------------------------------------------------------------- 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 Mar 14 01:35:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2E9ZT7f010634; Fri, 14 Mar 2003 01:35:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2E9ZThC010633; Fri, 14 Mar 2003 01:35:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2E9ZP7f010626 for ; Fri, 14 Mar 2003 01:35:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2E9ZXcU008333 for ; Fri, 14 Mar 2003 01:35:33 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09169 for ; Fri, 14 Mar 2003 01:35:27 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 09:35:27 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 09:35:26 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 09:35:26 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 09:35:25 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id BAA05250; Fri, 14 Mar 2003 01:35:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2E9ZNO19176; Fri, 14 Mar 2003 01:35:23 -0800 X-mProtect: <200303140935> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.41.239, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnTYUTh; Fri, 14 Mar 2003 01:35:21 PST Message-Id: <3E71A256.4030000@iprg.nokia.com> Date: Fri, 14 Mar 2003 01:35:18 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika Liljeberg CC: Ralph Droms , Pekka Savola , "Bound, Jim" , john.loughney@nokia.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipv6-node-requirements-03.txt References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB39@tayexc13.americas.cpqcorp.net> <4.3.2.7.2.20030313140410.051499b8@funnel.cisco.com> <1047591991.18624.126.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika Liljeberg wrote: >On Thu, 2003-03-13 at 21:09, Ralph Droms wrote: > > >>Your question does raise an interesting issue - where, in the IPv6 >>specifications, is the behavior of a router in response to received >>router advertisements specified? How does a router behave if >>it receives an RA with either or both of the 'M' and 'O' bits >>set? >> >> > >RFC2462 states several times that routers are not expected to process >router advertisements. > > RFC 2461, section 6.2.7 clearly does allow for routers processing router advertisements, i.e., for consistency verification. It concludes by saying: "Any other action on reception of Router Advertisement messages by a router is beyond the scope of this document." RFC 2462, section 4 says: "The remaining autoconfiguration steps are performed only by hosts; the (auto)configuration of routers is beyond the scope of this document." So, it doesn't appear to me that either specification covers the case in question. Fred Templin ftemplin@iprg.nokia.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 Fri Mar 14 05:42:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EDgm7f011387; Fri, 14 Mar 2003 05:42:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2EDgmAx011386; Fri, 14 Mar 2003 05:42:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EDgj7f011379 for ; Fri, 14 Mar 2003 05:42:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2EDgsjO003283 for ; Fri, 14 Mar 2003 05:42:54 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01376 for ; Fri, 14 Mar 2003 06:42:48 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:42:47 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:42:47 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:42:47 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:42:46 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2EDgUOI094862; Fri, 14 Mar 2003 14:42:30 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2EDgOxo273082; Fri, 14 Mar 2003 14:42:24 +0100 Received: from dhcp23-54.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA60288 from ; Fri, 14 Mar 2003 14:42:21 +0100 Message-Id: <3E71DC00.B902CFAC@hursley.ibm.com> Date: Fri, 14 Mar 2003 14:41:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com, Alex Conta , Bob Hinden & Margaret Wasserman Subject: Re: flow label -05 sec cons modification text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Apart from reserving the right to touch up the English, I have no trouble with Pekka's proposed additions. But what more is needed about ingress filtering? That seems to me to be a generic issue, with very little specificity to flow label attacks. Thanks Brian Pekka Savola wrote: > > Hello, > > Following up from the last call and the issues I raised, I'll try to > propose something to start with to make the security considerations more > in line with certain imporant issues. > > Note: I'm assuming that the sentence: > > A source node MUST ensure that it does not reuse Flow Label values it > is currently using or has recently used when creating new flows. > > will be changed, at least to "unintentionally reuse". > > Now, to the security considerations. > > 5.1 Theft and Denial of Service > > The goal of the Flow Label is to allow different levels of service to > be provided for traffic streams on a common network infrastructure. A > variety of techniques may be used to achieve this, but the end result > will be that some packets receive different (e.g., better or worse) > service than others. The mapping of network traffic to the flow- > specific treatment is triggered by the IP addresses and Flow Label > value of the IPv6 header, and hence an adversary may be able to > obtain better service by modifying the IPv6 header or by injecting > packets with false addresses and labels. Taken to its limits, such > ^^^ > > ==> false addresses _or_ labels. > > theft-of-service becomes a denial-of-service attack when the modified > or injected traffic depletes the resources available to forward it > and other traffic streams. > > ==> after this, add a new paragraph: > > Note that there is no guarantee that flow labels used in a node are > not used in any manner the node wants to, even reusing flow labels. > This is a feature: as nodes are typically untrusted, it cannot be > assumed that they would in fact implement or adhere to any restrictions > if such would be set -- and therefore any assumptions made by the > network on nodes' behaviour should be very limited except in > cases where the nodes are explicitly trusted. > > ==> and after the "Since flows.." paragraph, add paragraphs: > > There are two issues with different properties: > spoofing of only Flow Label, and spoofing of the whole 3-tuple, > including Source and Destination Address. > > The former can be done inside a node which is using the correct source > address. Being able to spoof Flow Label typically requires being in > position to also forge an address -- but in many cases, spoofing the > address may not be the interesting, especially if the spoofer's goal > is theft of service, not denial of service. > > The latter can be done by a host which is not subject to ingress > filtering [INGR] or an intermediate router. Due to its properties, > such is typically useful only for denial of service. > > ==> TODO: consider whether changes are needed (on ingress filtering) in > the second-last paragraph. > > Perhaps this should get one started. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 14 05:51:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EDpu7f011711; Fri, 14 Mar 2003 05:51:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2EDptEM011710; Fri, 14 Mar 2003 05:51:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EDpq7f011703 for ; Fri, 14 Mar 2003 05:51:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2EDq1jO004852 for ; Fri, 14 Mar 2003 05:52:01 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15150 for ; Fri, 14 Mar 2003 06:51:55 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:51:55 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:51:55 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:51:55 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 13:51:54 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2EDpnY31205; Fri, 14 Mar 2003 15:51:49 +0200 Date: Fri, 14 Mar 2003 15:51:49 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com, Alex Conta , Bob Hinden & Margaret Wasserman Subject: Re: flow label -05 sec cons modification text In-Reply-To: <3E71DC00.B902CFAC@hursley.ibm.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 14 Mar 2003, Brian E Carpenter wrote: > But what more is needed about ingress filtering? That seems > to me to be a generic issue, with very little specificity > to flow label attacks. What I meant is that there is some overlap with the text and some wordsmithing might be useful. No new text is needed, AFAICS. > Pekka Savola wrote: > > > > Hello, > > > > Following up from the last call and the issues I raised, I'll try to > > propose something to start with to make the security considerations more > > in line with certain imporant issues. > > > > Note: I'm assuming that the sentence: > > > > A source node MUST ensure that it does not reuse Flow Label values it > > is currently using or has recently used when creating new flows. > > > > will be changed, at least to "unintentionally reuse". > > > > Now, to the security considerations. > > > > 5.1 Theft and Denial of Service > > > > The goal of the Flow Label is to allow different levels of service to > > be provided for traffic streams on a common network infrastructure. A > > variety of techniques may be used to achieve this, but the end result > > will be that some packets receive different (e.g., better or worse) > > service than others. The mapping of network traffic to the flow- > > specific treatment is triggered by the IP addresses and Flow Label > > value of the IPv6 header, and hence an adversary may be able to > > obtain better service by modifying the IPv6 header or by injecting > > packets with false addresses and labels. Taken to its limits, such > > ^^^ > > > > ==> false addresses _or_ labels. > > > > theft-of-service becomes a denial-of-service attack when the modified > > or injected traffic depletes the resources available to forward it > > and other traffic streams. > > > > ==> after this, add a new paragraph: > > > > Note that there is no guarantee that flow labels used in a node are > > not used in any manner the node wants to, even reusing flow labels. > > This is a feature: as nodes are typically untrusted, it cannot be > > assumed that they would in fact implement or adhere to any restrictions > > if such would be set -- and therefore any assumptions made by the > > network on nodes' behaviour should be very limited except in > > cases where the nodes are explicitly trusted. > > > > ==> and after the "Since flows.." paragraph, add paragraphs: > > > > There are two issues with different properties: > > spoofing of only Flow Label, and spoofing of the whole 3-tuple, > > including Source and Destination Address. > > > > The former can be done inside a node which is using the correct source > > address. Being able to spoof Flow Label typically requires being in > > position to also forge an address -- but in many cases, spoofing the > > address may not be the interesting, especially if the spoofer's goal > > is theft of service, not denial of service. > > > > The latter can be done by a host which is not subject to ingress > > filtering [INGR] or an intermediate router. Due to its properties, > > such is typically useful only for denial of service. > > > > ==> TODO: consider whether changes are needed (on ingress filtering) in > > the second-last paragraph. > > > > Perhaps this should get one started. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 14 07:16:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EFGH7f012180; Fri, 14 Mar 2003 07:16:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2EFGH2G012179; Fri, 14 Mar 2003 07:16:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EFGE7f012172 for ; Fri, 14 Mar 2003 07:16:14 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2EFGMjO021280 for ; Fri, 14 Mar 2003 07:16:22 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21994 for ; Fri, 14 Mar 2003 07:16:17 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:16:16 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:16:15 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:16:15 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:16:11 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2EFFuEO074216; Fri, 14 Mar 2003 16:15:56 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2EFFrxo242070; Fri, 14 Mar 2003 16:15:54 +0100 Received: from dhcp23-54.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA63074 from ; Fri, 14 Mar 2003 16:15:45 +0100 Message-Id: <3E71F1E5.1011EB50@hursley.ibm.com> Date: Fri, 14 Mar 2003 16:14:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com, Alex Conta , Bob Hinden & Margaret Wasserman Subject: Re: flow label -05 sec cons modification text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Oh, OK. Wordsmithing I can manage! I doubt if we can do any more on this before the IETF. I only have 15 hours before I must be on a train to the airport, and 14.9 of them are reserved. Brian Pekka Savola wrote: > > On Fri, 14 Mar 2003, Brian E Carpenter wrote: > > But what more is needed about ingress filtering? That seems > > to me to be a generic issue, with very little specificity > > to flow label attacks. > > What I meant is that there is some overlap with the text and some > wordsmithing might be useful. No new text is needed, AFAICS. > > > Pekka Savola wrote: > > > > > > Hello, > > > > > > Following up from the last call and the issues I raised, I'll try to > > > propose something to start with to make the security considerations more > > > in line with certain imporant issues. > > > > > > Note: I'm assuming that the sentence: > > > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > is currently using or has recently used when creating new flows. > > > > > > will be changed, at least to "unintentionally reuse". > > > > > > Now, to the security considerations. > > > > > > 5.1 Theft and Denial of Service > > > > > > The goal of the Flow Label is to allow different levels of service to > > > be provided for traffic streams on a common network infrastructure. A > > > variety of techniques may be used to achieve this, but the end result > > > will be that some packets receive different (e.g., better or worse) > > > service than others. The mapping of network traffic to the flow- > > > specific treatment is triggered by the IP addresses and Flow Label > > > value of the IPv6 header, and hence an adversary may be able to > > > obtain better service by modifying the IPv6 header or by injecting > > > packets with false addresses and labels. Taken to its limits, such > > > ^^^ > > > > > > ==> false addresses _or_ labels. > > > > > > theft-of-service becomes a denial-of-service attack when the modified > > > or injected traffic depletes the resources available to forward it > > > and other traffic streams. > > > > > > ==> after this, add a new paragraph: > > > > > > Note that there is no guarantee that flow labels used in a node are > > > not used in any manner the node wants to, even reusing flow labels. > > > This is a feature: as nodes are typically untrusted, it cannot be > > > assumed that they would in fact implement or adhere to any restrictions > > > if such would be set -- and therefore any assumptions made by the > > > network on nodes' behaviour should be very limited except in > > > cases where the nodes are explicitly trusted. > > > > > > ==> and after the "Since flows.." paragraph, add paragraphs: > > > > > > There are two issues with different properties: > > > spoofing of only Flow Label, and spoofing of the whole 3-tuple, > > > including Source and Destination Address. > > > > > > The former can be done inside a node which is using the correct source > > > address. Being able to spoof Flow Label typically requires being in > > > position to also forge an address -- but in many cases, spoofing the > > > address may not be the interesting, especially if the spoofer's goal > > > is theft of service, not denial of service. > > > > > > The latter can be done by a host which is not subject to ingress > > > filtering [INGR] or an intermediate router. Due to its properties, > > > such is typically useful only for denial of service. > > > > > > ==> TODO: consider whether changes are needed (on ingress filtering) in > > > the second-last paragraph. > > > > > > Perhaps this should get one started. > > > > > > -- > > > Pekka Savola "You each name yourselves king, yet the > > > Netcore Oy kingdom bleeds." > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 14 07:39:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EFdL7f012749; Fri, 14 Mar 2003 07:39:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2EFdL3l012747; Fri, 14 Mar 2003 07:39:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EFdH7f012733 for ; Fri, 14 Mar 2003 07:39:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2EFdQcU024164 for ; Fri, 14 Mar 2003 07:39:26 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06888 for ; Fri, 14 Mar 2003 08:39:20 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:39:19 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:39:19 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:39:19 Z Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:39:17 Z Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) with ESMTP id h2EFdFYR009760 for ; Fri, 14 Mar 2003 17:39:15 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h2EFdFr6009756; Fri, 14 Mar 2003 17:39:15 +0200 Date: Fri, 14 Mar 2003 17:39:15 +0200 Message-Id: <200303141539.h2EFdFr6009756@burp.tkv.asdf.org> From: Markku Savela to: ipng@sunroof.eng.sun.com Subject: A problem with proxy address and ND probes? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just did some experiments with configuring a IPv6 global proxy address for an interface, and observed (for me) surprising effect: Everything went fine until the other end decided to do ND probe for the proxy address: dst=proxy src=x [... ICMP NS ...] Normal packet handling just looks at the IP header and decided quite correctly that this packet is not for me, but needs to be forwarded to the proxied host. => probes fail Seems that to get proxy address handling to work, one must in addition to looking at the destination address, also peek inside packet and look if it contains neighbor discovery packet for proxied address, and if so, instead of forwarding, treat the packet as if addressed to self. Of course, this is doable, but it kind of adds an "ugly wart" into normal packet processing path. Presumably, MIP6 Home Agent implementations already handle this somehow. Just thought to report this. At least for me, this aspect of the proxying didn't occur to me while implementing ND... -------------------------------------------------------------------- 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 Mar 14 07:49:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EFnu7f013321; Fri, 14 Mar 2003 07:49:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2EFnunG013320; Fri, 14 Mar 2003 07:49:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2EFnq7f013313 for ; Fri, 14 Mar 2003 07:49:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2EFo1jO029772 for ; Fri, 14 Mar 2003 07:50:01 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13932 for ; Fri, 14 Mar 2003 08:49:55 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:49:48 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:47:24 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:49:47 Z Received: from pguin2.txc.com (pguin2.txc.com [208.5.237.254]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 15:49:46 Z Received: from txc.com ([172.17.0.226]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id h2EFnes07990; Fri, 14 Mar 2003 10:49:41 -0500 Message-Id: <3E71FA8E.DD08A28D@txc.com> Date: Fri, 14 Mar 2003 10:51:42 -0500 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Pekka Savola , ipng@sunroof.eng.sun.com, Bob Hinden & Margaret Wasserman Subject: Re: flow label -05 sec cons modification text References: <3E71F1E5.1011EB50@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAD5755539994B802CC4BC38E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msAD5755539994B802CC4BC38E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pekka, Echoing Brian's message, I am comfortable with the authors working on fitting in the draft, after some wordsmithing, the text that you have proposed for the Security Section. Regards, Alex Brian E Carpenter wrote: > > Oh, OK. Wordsmithing I can manage! > > I doubt if we can do any more on this before the IETF. I only have 15 hours > before I must be on a train to the airport, and 14.9 of them are reserved. > > Brian > > Pekka Savola wrote: > > > > On Fri, 14 Mar 2003, Brian E Carpenter wrote: > > > But what more is needed about ingress filtering? That seems > > > to me to be a generic issue, with very little specificity > > > to flow label attacks. > > > > What I meant is that there is some overlap with the text and some > > wordsmithing might be useful. No new text is needed, AFAICS. > > > > > Pekka Savola wrote: > > > > > > > > Hello, > > > > > > > > Following up from the last call and the issues I raised, I'll try to > > > > propose something to start with to make the security considerations more > > > > in line with certain imporant issues. > > > > > > > > Note: I'm assuming that the sentence: > > > > > > > > A source node MUST ensure that it does not reuse Flow Label values it > > > > is currently using or has recently used when creating new flows. > > > > > > > > will be changed, at least to "unintentionally reuse". > > > > > > > > Now, to the security considerations. > > > > > > > > 5.1 Theft and Denial of Service > > > > > > > > The goal of the Flow Label is to allow different levels of service to > > > > be provided for traffic streams on a common network infrastructure. A > > > > variety of techniques may be used to achieve this, but the end result > > > > will be that some packets receive different (e.g., better or worse) > > > > service than others. The mapping of network traffic to the flow- > > > > specific treatment is triggered by the IP addresses and Flow Label > > > > value of the IPv6 header, and hence an adversary may be able to > > > > obtain better service by modifying the IPv6 header or by injecting > > > > packets with false addresses and labels. Taken to its limits, such > > > > ^^^ > > > > > > > > ==> false addresses _or_ labels. > > > > > > > > theft-of-service becomes a denial-of-service attack when the modified > > > > or injected traffic depletes the resources available to forward it > > > > and other traffic streams. > > > > > > > > ==> after this, add a new paragraph: > > > > > > > > Note that there is no guarantee that flow labels used in a node are > > > > not used in any manner the node wants to, even reusing flow labels. > > > > This is a feature: as nodes are typically untrusted, it cannot be > > > > assumed that they would in fact implement or adhere to any restrictions > > > > if such would be set -- and therefore any assumptions made by the > > > > network on nodes' behaviour should be very limited except in > > > > cases where the nodes are explicitly trusted. > > > > > > > > ==> and after the "Since flows.." paragraph, add paragraphs: > > > > > > > > There are two issues with different properties: > > > > spoofing of only Flow Label, and spoofing of the whole 3-tuple, > > > > including Source and Destination Address. > > > > > > > > The former can be done inside a node which is using the correct source > > > > address. Being able to spoof Flow Label typically requires being in > > > > position to also forge an address -- but in many cases, spoofing the > > > > address may not be the interesting, especially if the spoofer's goal > > > > is theft of service, not denial of service. > > > > > > > > The latter can be done by a host which is not subject to ingress > > > > filtering [INGR] or an intermediate router. Due to its properties, > > > > such is typically useful only for denial of service. > > > > > > > > ==> TODO: consider whether changes are needed (on ingress filtering) in > > > > the second-last paragraph. > > > > > > > > Perhaps this should get one started. > > > > > > > > -- > > > > Pekka Savola "You each name yourselves king, yet the > > > > Netcore Oy kingdom bleeds." > > > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- --------------msAD5755539994B802CC4BC38E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhAwgIjt1LtpV2AM64D0R8bCMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkyMDAwMDAw MFoXDTAzMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFIjccjs9g z0DiQcpTsg+mbY5L+R2YaTNN6k2fRGSLMLitaA2YwdeN3goXG45bXCP8DldBS38EWHFT2/5Q cy9HnNQaS1GnG2xzngdev5HpVm/oAy1M9YPt96Zp2W5MKGIb87vxyXvb1KqRMA9paf/6xZ2C B4tH127oHyF1xT4k8wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBUOS83AALNc8pTZDApKndtQBiFQLPTu5ZL pE1TDsyd4y75K3gXUvqlprCFY8HgKwodqs9wTltqYRlvhZVlMXu1y0g8Z3MJ9KSddePYuuli jop+PplaAHS7DHXDJNNQt+n2i2K4j4uJFokE2JnvaEyBEHjtTmIt+JjS2Dygm57mwzCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDCAiO3Uu2lXYAzrgPRHxsIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzAzMTQxNTUxNDRaMCMGCSqGSIb3DQEJ BDEWBBRbkB34V26/qMUkaSojl3tJg+VPBDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgMTpqPdpNzzApx7Y5zk1XGG23NpJUK5youFeogCO3kc+Ifb8 PdW/hG2DapLsyINBPhWDmhQnUCcuTYLaKtUykDuqtUq2KQTxW59LCIGK6rikLp1p53p8Sysa w2Li1fqCEUL3wI0Xj1lPALtm9Ej3GcQ7oZI40NzQMauoeWa8JKS7 --------------msAD5755539994B802CC4BC38E-- -------------------------------------------------------------------- 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 Mar 14 13:15:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ELFm7f016258; Fri, 14 Mar 2003 13:15:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ELFm98016257; Fri, 14 Mar 2003 13:15:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ELFj7f016250 for ; Fri, 14 Mar 2003 13:15:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ELFsjO018964 for ; Fri, 14 Mar 2003 13:15:54 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20754 for ; Fri, 14 Mar 2003 14:15:48 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 21:15:48 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 21:15:47 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 21:15:47 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 14 Mar 2003 21:15:47 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA02163 for ; Fri, 14 Mar 2003 13:15:37 -0800 (PST) Message-Id: <5.1.0.14.2.20030314161156.03f1c500@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 14 Mar 2003 16:13:25 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Final IPv6 WG Agenda for SF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, Attached please find the final IPv6 WG agenda for IETF 56. Margaret --- IPv6 Working Group (ipv6) Agenda IETF 56, San Francisco CHAIRS: Bob Hinden Margaret Wasserman First Session: Monday, March 17, 2003, 1930-2200 ================================================= Introduction and Agenda Bashing -- Bob Hinden (5 min) Updated Charter -- Bob Hinden (10 min) Action Plan -- Margaret Wasserman (15 min) Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-01.txt DHCP Option for Prefix Delegation -- Ole Troan (5 min) http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt Moving forward on Proxy RA Approach -- Bob Hinden (5 min) IPv6 MIBs: Forwarding, TCP & UDP MIBs Open Issues -- Margaret Wasserman (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2013-update-00.txt IP MIB Open Issues -- Shawn Routhier (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-02.txt IPv6 Addressing Architecture Appeal: Overview of IAB Response -- Leslie Daigle (20 min) http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt Working Group Response to Appeal Process -- Margaret Wasserman (10 min) Access Control Prefix RA Option -- Steve Bellovin (10 min) http://www.ietf.org/internet-drafts/draft-bellovin-ipv6-accessprefix-01.txt IPv6 Node Requirements, Open Issues -- John Loughney (30 min) http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-03.txt Analysis of IPv6 Anycast -- Itojun Hagino (10 min) http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt Second Session: Thursday, March 20, 2003, 0900-1130 =================================================== DHCPv6 DNS Resolver Configuration Option -- Ralph Droms (10 min) http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-03.txt IPv6 over Fibre Channel Review Request -- Claudio DeSanti (5 min) http://www.ietf.org/internet-drafts/draft-desanti-ipv6-over-fibre-channel-00.txt IPv6 Addressing Architecture Review of IAB Recommendations & Next Steps -- Margaret Wasserman (30 min) http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt Site-Local Addressing Impact of site-local addressing -- Margaret Wasserman (20 min) http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt "Limited Usage" Summary -- Margaret Wasserman (5 min) [See appendix of draft-wasserman-ipv6-sl-impact-02, above.] "Moderate Usage" Proposal -- Bob Hinden (15 min) http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-01.txt Chairs recommendation and discussion -- Chairs (30 min) -------------------------------------------------------------------- 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 Mar 15 01:38:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2F9cb7f020472; Sat, 15 Mar 2003 01:38:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2F9cbkp020471; Sat, 15 Mar 2003 01:38:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2F9cX7f020464 for ; Sat, 15 Mar 2003 01:38:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2F9cfcU018432 for ; Sat, 15 Mar 2003 01:38:41 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17602 for ; Sat, 15 Mar 2003 02:38:36 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 09:38:35 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 09:38:29 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 09:38:29 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 09:38:27 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id ED8DB15248; Sat, 15 Mar 2003 18:38:21 +0900 (JST) Date: Sat, 15 Mar 2003 18:38:42 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: comments on sl-impact-02 User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 280 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've finally read draft-wasserman-ipv6-sl-impact-02.txt. (I admit I should have done it much earlier...) (Just to make my position clear) First of all, I'm not a fun of site-local (SL) addresses, and agree on limiting the use of SLs *to some extent*. So, I'm not intending to criticize the draft. General comments: I respect the coverage of the draft, but at the same time, I have several concerns: - many issues described in the draft are specific to site-border (multi-sited) nodes. Since we had a consensus of eliminating the multi-sited case, it would be much simpler and clearer to concentrate on single-site cases. The current draft seems to impose too much negative impression on generic SL issues using issues specific to multi-sited cases. - the draft often uses the words "complex" and "complexity". Although I agree that many of them are real issues, I'm afraid such wording tends to cause subjective discussions. Also, some of the "complexity" can be dealt with a generic approach applicable to both link-local and site-local addresses, as I tried to describe below. We should concentrate on complexities specific to SLs in the draft, and should be careful if each "complexity" is the case and is a real issue. - I cannot still be convinced about the "Limited Use" proposal stated in Appendix. It is true that all the issues described in the draft can be solved by the "Limited Use". However, just saying "IPv6 site-local addresses should be reserved for use on isolated, single-site networks" introduces another issues about intermittently connected sites or sites migrating from isolated networks to globally-connected ones. So the current "Limited Use" proposal is just shifting one set of problems to another, at least to me. At this moment, a reasonable compromise is to describe the issues and to let administrators use SLs in a globally-connected site at their own risk. Detailed comments follow: Abstract Although there are several benefits attributed to site-local addressing, some of those benefits can be more easily achieved through less problematic mechanisms. Hmm, what exactly are the "less problematic mechanisms"? The draft often refers to provider independent global addresses, but they are not available at this moment and have their own issues. So if the "less problematic mechanisms" include provider independent global addresses, it's not fair just to say " can be more easily achieved." 3.1.2.1 Problems for All Site-Border Nodes Some people have commented that the same problems exist for link- local addresses, but this is not entirely true. Link-local addresses can use an existing identifier, the interface name or number, as their qualifier, while site-local addresses require the configuration of an artificial zone ID. Technically, this is not really true since links are larger scope than interfaces. In general, link-local addresses will only be used for specialized purposes or on single-link networks where they can be treated exactly like global addresses. I agree about the DNS issue. But I, as an operator of IPv6 networks, often use ping or ssh on a router (i.e., a multi-link nodes) with disambiguating an appropriate link. Is such usage included in the "general" use? 3.1.2.2 Problems for Site-Border Routers All IPv6 routers will need to check all forwarded packets to determine if either the source or destination is link-local. If so, the packet will be discarded and an appropriate ICMP error message will be generated. The procedure cannot be that simple. First, (again) since links are larger than interfaces, it is possible for a router to forward a packet with a link-local source or destination from an interface to another one. Even in the default configuration where there is a one-to-one mapping between links and interfaces, a router can receive a packet with a link-local destination from an interface and forward it back to the same interface. While the draft says: If the destination address is site-local, the router will look at the interface on which the packet was received to determine the site-local zone in which the packet originated, and will perform a lookup in the correct site-local forwarding table and forward the packet, as indicated. However, this should also apply to link-local addresses as I said above. And, in fact, our implementation adopts a generic forwarding routine used for all type of scopes like this: /* Source scope check. rt_ifp is the outgoing interface for dst */ in6_addr2zoneid(rt->rt_ifp, &ip6->ip6_src, &zone); if (sa6_src.sin6_scope_id != zone) { icmp6_error(mcopy, ICMP6_DST_UNREACH, ICMP6_DST_UNREACH_BEYONDSCOPE, 0); } /* Destination scope check */ in6_addr2zoneid(rt->rt_ifp, &ip6->ip6_dst, &zone); if (sa6_dst.sin6_scope_id != zone) { m_freem(m); return; } (I simplified the actual code for brevity. The full source can be obtained from the KAME web site.) 3.3.1 DNS Server Issues In summary, it seems to me that this section mixes site-local specific issues and other DNS issues, though I admit SLs may introduce additional complexity to the other issues. The first part of this section apparently talks about generic issues of split DNS. Though it would be true that the use of SLs inherently requires (a kind of) split DNS, I also guess that enterprise operators will still use split DNS even if they only have global addresses, in order to hide host names of the intranet. If this is the case, the issues introduced by split DNS are not so tightly related to SLs. The second part of this section talks about the home or SO-HO network case. In this case, we'll first solve an even harder issue; how to register home or SO-HO host names to the name server in the ISP network. If we really cannot solve this, the question about the SL implication is also meaningless. If we can solve this, I also think SL related issues can be addressed using per-office configuration in the ISP DNS server. 3.3.2.1 DNS Resolver Issues for All IPv6 Nodes The current address selection rules prefer site-local destinations, so that site-local addresses will be used, if available. (This is just an editorial comment) More precisely, the address selection rules prefer smaller-scope destinations. The DNS resolver must also specify a zone ID for any site-local addresses that are included in the address list returned to the calling application. [....snip] I'm a bit confused. Isn't this an issue only for site-border resolvers? Why is this paragraph here, not in 3.3.2.2? For example, this mechanism would not work properly when a local caching resolver is used. In this common configuration, ... What exactly do you mean by "a local caching resolver"? Do you mean, e.g. a BIND DNS caching server running on the same node of the resolver? If so, I don't think this is not a so common configuration. 3.3.2.2 DNS Resolver Issues for Site-Border Nodes So, Node-1 will never receive site-local addresses for nodes in Site-B. Node-1 will not realize I think this is over-simplification (or does not describe the actual issue). Technically, DNS-A can also store site-local addresses for site-B. The essential problem here is that Node-1 cannot disambiguate the site-local addresses returned from DNS-A. (So, as a conclusion, I agree that this is a problematic case.) 3.4 Mobile IPv6 Issues The use of site-local addresses in the MIPv6 home address option may cause security concerns. If site-local addresses are used as an access control mechanism, it is important that MIPv6 implementations do not represent packets to upper layers as being addressed to or from site-local addresses if those packets may actually have originated outside of the local site. I don't get why this is specific to SLs. It seems to me this is a general issue like "if particular prefixes (as a home address) are used as an access control mechanism, it is important ...". 3.6 Network Management Issues This problem also exists for link-local addresses. However, the inclusion of site-local addresses in the DNS, preferring them in address selection rules, and using them for access control could result in site-local addresses being used much more widely than link-local addresses. Is this really true? In network management cases, I believe we'll see many link-local addresses off-link, since all IGP uses link-local addresses to represent next-hops. 3.7 Application Protocol Issues The application space can be broken down into several categories, each of which will be impacted differently by IPv6 site-local addressing: This classification is very helpful, but it would be much better with concrete examples. In fact, I've seen requirements for concrete examples on IPv4 link-local discussions in the zeroconf ML so many times. Answering the requirements here would simplify future discussions. Application user-interfaces will need to support the inclusion of a zone ID whenever an IP address is entered by the user, I'm not 100% sure what "Application user-interfaces" means here. Scope-aware getaddrinfo() can provide a transparent user-interface to specify zone ID, regardless of the scope type. and applications will have to add a default zone ID to IP addresses when one is not provided. This is not necessarily true, or at least an implementation dependent. In fact, implementation in fact supports the ability to set a default zone ID in the kernel, so that applications need not be scope-aware. 3.8.1 IP Security Issues (Just as a comment) The problem described in this section is specific to scope-border nodes (i.e., site-border nodes for the site-local case). Also, the same problem exist for link-local addresses. 3.8.2 Key Exchange Protocol Issues Key exchange protocols pass around information that is used to populate security tables. In order for appropriate security policies to be enforced for site-local communication, keys will need to be distributed for site-local IPv6 addresses. This is okay, but However, key exchange protocols are unaware of site boundaries, and it is unclear how they will determine how far site-local keying information should be distributed. I don't understand this. I'm not even sure if this is a description about key exchange protocols in general or if this assumes a particular key exchange protocols such as IKE. Could you be more specific? 4.3 Networks behind NATs This includes IPv6 sites that are connected to the IPv4 Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT], as well as IPv6 sites that may be connected to an IPv6 Internet using IPv6-to-IPv6 NAT. I don't understand the intended usage about sites using IPv6-to-IPv6 NAT. Could you be more specific please? 4.5.1 Site-Local Access Control and Tunneling It seems to me this section talks about generic security issues on tunneling, not ones specific to SLs. 12 Appendix A: "Limited Use" Proposal So, the author of this document recommends that IPv6 site-local addresses be reserved for use on isolated, single-site networks or behind NATs (either IPv4-to-IPv6 or IPv6-to-IPv6 NATs). Do you actually mean IPv6-to-IPv4 NAT (not IPv4-to-IPv6)? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 15 03:44:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FBi87f020833; Sat, 15 Mar 2003 03:44:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2FBi8Rm020832; Sat, 15 Mar 2003 03:44:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FBi57f020825 for ; Sat, 15 Mar 2003 03:44:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2FBiCjO021691 for ; Sat, 15 Mar 2003 03:44:13 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01892 for ; Sat, 15 Mar 2003 03:44:07 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 11:44:06 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 11:41:40 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 11:44:05 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 11:44:04 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2FBijwY013355; Sat, 15 Mar 2003 13:44:46 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2FBieSK013353; Sat, 15 Mar 2003 13:44:40 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: comments on sl-impact-02 From: Mika Liljeberg To: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= Cc: mrw@windriver.com, ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1047728679.13132.8.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Mar 2003 13:44:40 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2FBi57f020826 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2003-03-15 at 11:38, JINMEI Tatuya / 神明é”哉 wrote: > While the draft says: > > If the destination address is site-local, the router will look at > the interface on which the packet was received to determine the > site-local zone in which the packet originated, and will perform a > lookup in the correct site-local forwarding table and forward the > packet, as indicated. > > However, this should also apply to link-local addresses as I said > above. And, in fact, our implementation adopts a generic forwarding > routine used for all type of scopes like this: > > /* Source scope check. rt_ifp is the outgoing interface for dst */ > in6_addr2zoneid(rt->rt_ifp, &ip6->ip6_src, &zone); > if (sa6_src.sin6_scope_id != zone) { > icmp6_error(mcopy, ICMP6_DST_UNREACH, > ICMP6_DST_UNREACH_BEYONDSCOPE, 0); > } > > /* Destination scope check */ > in6_addr2zoneid(rt->rt_ifp, &ip6->ip6_dst, &zone); > if (sa6_dst.sin6_scope_id != zone) { > m_freem(m); > return; > } Exactly. Our implementation does the same thing. While the text in SCOPARCH is already reasonably clear on this, I think this is important enough that it would be worthwhile to put the above code into SCOPARCH in pseudo code format. MikaL -------------------------------------------------------------------- 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 Mar 15 04:42:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FCgX7f021185; Sat, 15 Mar 2003 04:42:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2FCgXN9021184; Sat, 15 Mar 2003 04:42:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FCgU7f021177 for ; Sat, 15 Mar 2003 04:42:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2FCgbjO029359 for ; Sat, 15 Mar 2003 04:42:38 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10497 for ; Sat, 15 Mar 2003 05:42:32 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 12:42:32 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 12:42:31 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 12:42:31 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 12:42:31 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.2]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA14373; Sat, 15 Mar 2003 04:42:18 -0800 (PST) Message-Id: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 15 Mar 2003 07:40:45 -0500 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Margaret Wasserman Subject: Re: comments on sl-impact-02 Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jinmei, Thank you for your detailed feedback. A few questions about your response... I'll try to respond to the more substantive points later. > 3.1.2.1 Problems for All Site-Border Nodes > > Some people have commented that the same problems exist for link- > local addresses, but this is not entirely true. Link-local > addresses can use an existing identifier, the interface name or > number, as their qualifier, while site-local addresses require the > configuration of an artificial zone ID. > >Technically, this is not really true since links are larger scope than >interfaces. Does anyone have an implementation today that has any special handling for multi-interface links? If you want to send a packet to a LL address, are you supposed to send it out all of the interfaces for that link, or only one of them (if so, which one)? > In general, link-local addresses will only be used for > specialized purposes or on single-link networks where they can be > treated exactly like global addresses. > >I agree about the DNS issue. > >But I, as an operator of IPv6 networks, often use ping or ssh on a router >(i.e., a multi-link nodes) with disambiguating an appropriate link. >Is such usage included in the "general" use? I don't know... What are you doing this for? If you are doing it to configure and test a router, then I would say 'no', this isn't general use. >3.1.2.2 Problems for Site-Border Routers > > All IPv6 routers will need to check > all forwarded packets to determine if either the source or > destination is link-local. If so, the packet will be discarded and > an appropriate ICMP error message will be generated. > >The procedure cannot be that simple. First, (again) since links are >larger than interfaces, it is possible for a router to forward a >packet with a link-local source or destination from an interface to >another one. Even in the default configuration where there is a >one-to-one mapping between links and interfaces, a router can receive >a packet with a link-local destination from an interface and forward >it back to the same interface. We definitely need to discuss this "links are larger than interfaces" concept... This will probably lead to link-local addresses having more of the problems associated with site-local addresses than I originally thought. > The DNS resolver must also specify a zone ID for any site-local > addresses that are included in the address list returned to the > calling application. [....snip] > >I'm a bit confused. Isn't this an issue only for site-border >resolvers? Why is this paragraph here, not in 3.3.2.2? Actually, all hosts will have to insert a zone ID. It will be easier to do this on single-site systems (since they only have one ID to insert), but it is needed on all systems. I could make this clearer. > For example, this mechanism would not work properly when a local > caching resolver is used. In this common configuration, ... > >What exactly do you mean by "a local caching resolver"? Do you mean, >e.g. a BIND DNS caching server running on the same node of the >resolver? If so, I don't think this is not a so common >configuration. I'll have to ask whoever sent me the text :-). I think it was Rob Austein. > Application user-interfaces will need to support the inclusion of a > zone ID whenever an IP address is entered by the user, > >I'm not 100% sure what "Application user-interfaces" means here. >Scope-aware getaddrinfo() can provide a transparent user-interface to >specify zone ID, regardless of the scope type. Sorry, I don't understand your statement, either. If the application has a dialogue box in which the customer can specify an IP address (instead of a host name), the UI will need to allow the user to enter a zone ID, as well. That isn't true in IPv4, but it will be needed in IPv6. > and > applications will have to add a default zone ID to IP addresses > when one is not provided. > >This is not necessarily true, or at least an implementation dependent. >In fact, implementation in fact supports the ability to set a default >zone ID in the kernel, so that applications need not be scope-aware. Do you set a default zone ID for each scope? So, there would be a default link and a default site? > 4.3 Networks behind NATs > > This includes IPv6 sites that are connected to the IPv4 > Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT], > as well as IPv6 sites that may be connected to an IPv6 Internet > using IPv6-to-IPv6 NAT. > >I don't understand the intended usage about sites using IPv6-to-IPv6 >NAT. Could you be more specific please? We don't have any plans to provide portable addresses in IPv6, so people will end-up deploying IPv6<->IPv6 NAT in order to gain address portability/ISP-independence for their internal addresses. I don't like this, but I consider it a fact of life. When they do deploy IPv6<->IPv6 NAT, it is important to have a set of readily-identifiable non-global addresses to use behind the NAT, so that we can prefer IPv4 global addresses to local IPv6 addresses (and vice versa). I am suggesting that site-local addresses be used for this purpose. > 12 Appendix A: "Limited Use" Proposal > > So, the author of this document recommends that IPv6 site-local > addresses be reserved for use on isolated, single-site networks or > behind NATs (either IPv4-to-IPv6 or IPv6-to-IPv6 NATs). > >Do you actually mean IPv6-to-IPv4 NAT (not IPv4-to-IPv6)? I mean both NAT-PT (IPv4<->IPv6) and IPv6<->IPv6 NAT (translating internal IPv6 addresses to external IPv6 addresses). Margaret -------------------------------------------------------------------- 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 Mar 15 06:23:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FENM7f021579; Sat, 15 Mar 2003 06:23:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2FENMGF021578; Sat, 15 Mar 2003 06:23:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FENI7f021571 for ; Sat, 15 Mar 2003 06:23:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2FENQjO013658 for ; Sat, 15 Mar 2003 06:23:26 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05293 for ; Sat, 15 Mar 2003 07:23:20 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:23:20 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:23:19 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:23:19 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:23:19 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2FEO2wY013970; Sat, 15 Mar 2003 16:24:02 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2FEO0wt013967; Sat, 15 Mar 2003 16:24:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: comments on sl-impact-02 From: Mika Liljeberg To: Margaret Wasserman Cc: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= , ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> References: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047738239.13132.52.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Mar 2003 16:24:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, On Sat, 2003-03-15 at 14:40, Margaret Wasserman wrote: > > For example, this mechanism would not work properly when a local > > caching resolver is used. In this common configuration, ... > > > >What exactly do you mean by "a local caching resolver"? Do you mean, > >e.g. a BIND DNS caching server running on the same node of the > >resolver? If so, I don't think this is not a so common > >configuration. > > I'll have to ask whoever sent me the text :-). I think it was > Rob Austein. It's not so unheard of to run a local copy of BIND for caching. I used to do this at home myself when my ISP was having problems with their DNS servers. Some people also routinely use pdnsd with their Linux/FreeBSD boxes: http://home.t-online.de/home/Moestl/ > > and > > applications will have to add a default zone ID to IP addresses > > when one is not provided. > > > >This is not necessarily true, or at least an implementation dependent. > >In fact, implementation in fact supports the ability to set a default > >zone ID in the kernel, so that applications need not be scope-aware. > > Do you set a default zone ID for each scope? So, there would be a > default link and a default site? I can't comment on the KAME implementation, but in general you can just specify a default interface and read the default zone IDs for each scope level from the scope table of that interface. Our implementation actually has a mechanism, whereby we let the stack select the default interface, but we can constrain the set of possible interfaces to any specific zone. So we can say, for instance, pick any interface from this link, or pick any interface from this site. MikaL -------------------------------------------------------------------- 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 Mar 15 06:31:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FEVx7f021841; Sat, 15 Mar 2003 06:31:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2FEVxNH021840; Sat, 15 Mar 2003 06:31:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FEVu7f021833 for ; Sat, 15 Mar 2003 06:31:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2FEW3jO015089 for ; Sat, 15 Mar 2003 06:32:04 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08224 for ; Sat, 15 Mar 2003 07:31:58 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:31:58 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:31:57 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:31:57 Z Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 14:31:56 Z Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) with ESMTP id h2FEVTYR024078; Sat, 15 Mar 2003 16:31:29 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h2FEVSf4024074; Sat, 15 Mar 2003 16:31:28 +0200 Date: Sat, 15 Mar 2003 16:31:28 +0200 Message-Id: <200303151431.h2FEVSf4024074@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com In-reply-to: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> (message from Margaret Wasserman on Sat, 15 Mar 2003 07:40:45 -0500) Subject: Re: comments on sl-impact-02 References: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Technically, this is not really true since links are larger scope than > >interfaces. > > Does anyone have an implementation today that has any special > handling for multi-interface links? If you want to send a > packet to a LL address, are you supposed to send it out all of > the interfaces for that link, or only one of them (if so, which > one)? No special handling, you can just have multiple interfaces on the same link. When sending to a link local address, system picks one interface (unless application or some other configuration setting does not give some preference). > If the application has a dialogue box in which the customer can specify > an IP address (instead of a host name), the UI will need to allow the > user to enter a zone ID, as well. That isn't true in IPv4, but it will > be needed in IPv6. Actually, almost similar thing is needed in IPv4 due nasty use of private addresses (ISP offers link with 10-net addresses, and your company has also internal net with 10-net addresses (via VPN tunnel). Now, when you type in addresses, you need to specify whether you mean address within ISP space or company space... And, even nastier, you have to specify the "scope" for DNS too: resolve from ISP nameserver or company nameserver (via VPN)? Not really doably with traditional IPv4 stack, but with scoped IPv6/4 stack you can actually make it work. -------------------------------------------------------------------- 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 Mar 15 08:07:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FG7h7f022327; Sat, 15 Mar 2003 08:07:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2FG7hCo022326; Sat, 15 Mar 2003 08:07:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FG7c7f022319 for ; Sat, 15 Mar 2003 08:07:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2FG7kcU017608 for ; Sat, 15 Mar 2003 08:07:46 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09391 for ; Sat, 15 Mar 2003 09:07:40 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:07:39 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:07:38 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:07:38 Z Received: from soln-sro177.solutionip.com (soln-sro177.solutionip.com [12.36.112.226]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:07:38 Z Received: from [12.44.189.51] (helo=starfruit.itojun.org) by soln-sro177.solutionip.com with esmtp (Exim 3.34 #1) id 18uEC9-0007Dm-00 for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 08:07:37 -0800 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E167F791; Sun, 16 Mar 2003 01:06:59 +0900 (JST) To: Markku Savela Cc: mrw@windriver.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com In-reply-to: msa's message of Sat, 15 Mar 2003 16:31:28 +0200. <200303151431.h2FEVSf4024074@burp.tkv.asdf.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: comments on sl-impact-02 From: Jun-ichiro itojun Hagino Date: Sun, 16 Mar 2003 01:06:59 +0900 Message-Id: <20030315160659.E167F791@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >Technically, this is not really true since links are larger scope than >> >interfaces. >> Does anyone have an implementation today that has any special >> handling for multi-interface links? If you want to send a >> packet to a LL address, are you supposed to send it out all of >> the interfaces for that link, or only one of them (if so, which >> one)? >No special handling, you can just have multiple interfaces on the same >link. When sending to a link local address, system picks one interface >(unless application or some other configuration setting does not give >some preference). to be clear: for outgoing packet, that should be enough. for incoming packet, you will need to have a mapping table of interface id -> link id and translate id accordingly and use "fe80::1%linkX" as the identifier for the peer. >> If the application has a dialogue box in which the customer can specify >> an IP address (instead of a host name), the UI will need to allow the >> user to enter a zone ID, as well. That isn't true in IPv4, but it will >> be needed in IPv6. >Actually, almost similar thing is needed in IPv4 due nasty use of >private addresses (ISP offers link with 10-net addresses, and your >company has also internal net with 10-net addresses (via VPN >tunnel). Now, when you type in addresses, you need to specify whether >you mean address within ISP space or company space... And, even >nastier, you have to specify the "scope" for DNS too: resolve from ISP >nameserver or company nameserver (via VPN)? Not really doably with >traditional IPv4 stack, but with scoped IPv6/4 stack you can actually >make it work. the key issue here is whether to mandate the above nastiness (multiple routing table for fec0::/10 space) for every node or not. i personally vote for simpler implementation, therefore vote for very limited site-local address usage. itojun -------------------------------------------------------------------- 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 Mar 15 08:15:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FGFr7f022594; Sat, 15 Mar 2003 08:15:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2FGFr8Y022593; Sat, 15 Mar 2003 08:15:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FGFo7f022586 for ; Sat, 15 Mar 2003 08:15:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2FGFvjO029345 for ; Sat, 15 Mar 2003 08:15:58 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14518 for ; Sat, 15 Mar 2003 09:15:52 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:15:37 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:15:37 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:15:37 Z Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:15:36 Z Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) with ESMTP id h2FGFPYR024990; Sat, 15 Mar 2003 18:15:25 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h2FGFPNS024986; Sat, 15 Mar 2003 18:15:25 +0200 Date: Sat, 15 Mar 2003 18:15:25 +0200 Message-Id: <200303151615.h2FGFPNS024986@burp.tkv.asdf.org> From: Markku Savela To: itojun@iijlab.net CC: mrw@windriver.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com In-reply-to: <20030315160659.E167F791@starfruit.itojun.org> (message from Jun-ichiro itojun Hagino on Sun, 16 Mar 2003 01:06:59 +0900) Subject: Re: comments on sl-impact-02 References: <20030315160659.E167F791@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > to be clear: for outgoing packet, that should be enough. for incoming > packet, you will need to have a mapping table of > interface id -> link id > and translate id accordingly and use "fe80::1%linkX" as the identifier > for the peer. Such mapping is very simple: you just have each interface associated array of scope id's (16). For incoming packet, you just complete the source and destination addresses with: linkX = interface->scopes[scope_of_addr]. Works also for multicast destinations, which may have almost any scope. -------------------------------------------------------------------- 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 Mar 15 08:41:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FGfI7f022981; Sat, 15 Mar 2003 08:41:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2FGfH9k022980; Sat, 15 Mar 2003 08:41:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2FGfE7f022973 for ; Sat, 15 Mar 2003 08:41:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2FGfMcU024425 for ; Sat, 15 Mar 2003 08:41:22 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23403 for ; Sat, 15 Mar 2003 08:41:17 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:41:16 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:41:16 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:41:16 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 15 Mar 2003 16:41:15 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2FGfnwY014918; Sat, 15 Mar 2003 18:41:50 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2FGfjCL014914; Sat, 15 Mar 2003 18:41:45 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: comments on sl-impact-02 From: Mika Liljeberg To: Jun-ichiro itojun Hagino Cc: Markku Savela , mrw@windriver.com, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com In-Reply-To: <20030315160659.E167F791@starfruit.itojun.org> References: <20030315160659.E167F791@starfruit.itojun.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047746505.13140.61.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Mar 2003 18:41:45 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2003-03-15 at 18:06, Jun-ichiro itojun Hagino wrote: > the key issue here is whether to mandate the above nastiness (multiple > routing table for fec0::/10 space) for every node or not. i personally > vote for simpler implementation, therefore vote for very limited > site-local address usage. Pending GUPI addresses, it's hard to see how such nastiness can be avoided with nodes that must occupy a site border (e.g. wireless hosts that connect to more than one site). Not that a full implementation needs to be mandated for all nodes, but the applicability of a simpler implementation will necessaarily be limited to single-site contexts. MikaL -------------------------------------------------------------------- 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 Mar 15 20:59:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2G4xt7f025435; Sat, 15 Mar 2003 20:59:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2G4xtoo025434; Sat, 15 Mar 2003 20:59:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2G4xq7f025427 for ; Sat, 15 Mar 2003 20:59:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2G4xxcU023953 for ; Sat, 15 Mar 2003 20:59:59 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA28749 for ; Sat, 15 Mar 2003 21:59:53 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 04:59:53 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 04:59:52 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 04:59:52 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 04:59:51 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F00E4390D; Sat, 15 Mar 2003 23:59:50 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 23:59:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Sat, 15 Mar 2003 23:59:50 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB3@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLplB65RLYV7bX7Rdi/Ovg09ieNbwB5J+CQ From: "Bound, Jim" To: "Ralph Droms" , "Pekka Savola" Cc: , , X-OriginalArrivalTime: 16 Mar 2003 04:59:50.0888 (UTC) FILETIME=[E0246680:01C2EB78] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2G4xq7f025428 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My dhcp/nat box does same as Ralphs too and also in my basement :--) /jim >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, March 13, 2003 2:09 PM >To: Pekka Savola >Cc: Bound, Jim; john.loughney@nokia.com; >brian@hursley.ibm.com; ipng@sunroof.eng.sun.com >Subject: RE: draft-ietf-ipv6-node-requirements-03.txt > > >At 09:06 AM 3/12/2003 +0200, Pekka Savola wrote: >>On Tue, 11 Mar 2003, Bound, Jim wrote: >> > In addition the Enterprise wireline networks and IT are >not going to >> > give up stateful control with servers and NAS in their >networks for >> > a long time with IPv6 is my intelligence from my work with users. >> >>Are servers and NAS configured with DHCPv4 today? > >Yes. The home NAT/router in my basement acts as a DHCP client >on the interface connected to the ISP and as a DHCP server on >the interface to my home network. > >Your question does raise an interesting issue - where, in the >IPv6 specifications, is the behavior of a router in response >to received router advertisements specified? How does a >router behave if it receives an RA with either or both of the >'M' and 'O' bits set? > >Note that the DHCPv6 doesn't include the infamous sentence: >"DHCP is not intended for use in configuring routers." > >I certainly anticipate routers using DHCPv6 for obtaining DNS >and similar configuration information, as well as prefix delegation... > >- Ralph > > >>Not that I know of, we certainly don't do it (even though we >use DHCPv4 >>for most workstations). Of course, that's possible, e.g. by >>identifying MAC-address in the servers etc., but I'm not sure if all >>that many folks do it. >> >>Don't underestimate the power of an admin doing manual configuration. >>:-) >> >>So, my point is that there's a lot more to it than just "stateful" or >>"stateless". >> >>The critical point, IMO, is making the nodes able to easily configure >>other parameters they'd like, using DHCP-lite, or other >mechanisms like >>that. Few people prefer to punch all of that in manually. >> >>-- >>Pekka Savola "You each name yourselves king, yet the >>Netcore Oy kingdom bleeds." >>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> >>-------------------------------------------------------------------- >>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 Sat Mar 15 21:13:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2G5Ds7f025661; Sat, 15 Mar 2003 21:13:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2G5Dsgv025660; Sat, 15 Mar 2003 21:13:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2G5Do7f025653 for ; Sat, 15 Mar 2003 21:13:51 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2G5DwjO023224 for ; Sat, 15 Mar 2003 21:13:59 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29145 for ; Sat, 15 Mar 2003 21:13:51 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 05:13:48 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 04:56:16 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 04:58:43 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 04:58:42 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0580997B; Sat, 15 Mar 2003 23:58:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 23:58:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-node-requirements-03.txt Date: Sat, 15 Mar 2003 23:58:41 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B0324103B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-node-requirements-03.txt Thread-Index: AcLplB65RLYV7bX7Rdi/Ovg09ieNbwB4/iOA From: "Bound, Jim" To: "Ralph Droms" , "Pekka Savola" Cc: , , X-OriginalArrivalTime: 16 Mar 2003 04:58:41.0873 (UTC) FILETIME=[B7018C10:01C2EB78] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2G5Dp7f025654 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think DHCPv6 getting M/O bits from CPE routers makes sense too? Nothing prohibits it. It was just left out of scope during ND and Addrconf discussions and to keep focus on the end systems as target for RAs. There is lots of stuff a router could get from dhcpv6 server like where are my HLR and VLRs for Telco network or what SS7/IP gateway do I speak with. Makes me even more convinced Brian's words with SHOULD for M/O bits in node requirements is definitely a SHOULD. /jim >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, March 13, 2003 2:09 PM >To: Pekka Savola >Cc: Bound, Jim; john.loughney@nokia.com; >brian@hursley.ibm.com; ipng@sunroof.eng.sun.com >Subject: RE: draft-ietf-ipv6-node-requirements-03.txt > > >At 09:06 AM 3/12/2003 +0200, Pekka Savola wrote: >>On Tue, 11 Mar 2003, Bound, Jim wrote: >> > In addition the Enterprise wireline networks and IT are >not going to >> > give up stateful control with servers and NAS in their >networks for >> > a long time with IPv6 is my intelligence from my work with users. >> >>Are servers and NAS configured with DHCPv4 today? > >Yes. The home NAT/router in my basement acts as a DHCP client >on the interface connected to the ISP and as a DHCP server on >the interface to my home network. > >Your question does raise an interesting issue - where, in the >IPv6 specifications, is the behavior of a router in response >to received router advertisements specified? How does a >router behave if it receives an RA with either or both of the >'M' and 'O' bits set? > >Note that the DHCPv6 doesn't include the infamous sentence: >"DHCP is not intended for use in configuring routers." > >I certainly anticipate routers using DHCPv6 for obtaining DNS >and similar configuration information, as well as prefix delegation... > >- Ralph > > >>Not that I know of, we certainly don't do it (even though we >use DHCPv4 >>for most workstations). Of course, that's possible, e.g. by >>identifying MAC-address in the servers etc., but I'm not sure if all >>that many folks do it. >> >>Don't underestimate the power of an admin doing manual configuration. >>:-) >> >>So, my point is that there's a lot more to it than just "stateful" or >>"stateless". >> >>The critical point, IMO, is making the nodes able to easily configure >>other parameters they'd like, using DHCP-lite, or other >mechanisms like >>that. Few people prefer to punch all of that in manually. >> >>-- >>Pekka Savola "You each name yourselves king, yet the >>Netcore Oy kingdom bleeds." >>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >> >> >>-------------------------------------------------------------------- >>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 Sat Mar 15 22:50:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2G6oS7f026108; Sat, 15 Mar 2003 22:50:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2G6oSxI026107; Sat, 15 Mar 2003 22:50:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2G6oN7f026100 for ; Sat, 15 Mar 2003 22:50:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2G6oVcU007648 for ; Sat, 15 Mar 2003 22:50:31 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06366 for ; Sat, 15 Mar 2003 23:50:24 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 06:50:13 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 06:50:13 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 06:50:13 Z Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 06:50:08 Z Received: from bigmail.research.att.com (H-135-207-30-101.research.att.com [135.207.30.101]) by mail-pink.research.att.com (Postfix) with ESMTP id 67F1E5821C; Sun, 16 Mar 2003 01:39:29 -0500 (EST) Received: from berkshire.research.att.com (guard.research.att.com [135.207.1.20]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h2G6o3L09014; Sun, 16 Mar 2003 01:50:04 -0500 (EST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 7131F7B87; Sat, 15 Mar 2003 23:18:33 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jari Arkko Cc: Pekka Savola , ipng@sunroof.eng.sun.com, bzill@microsoft.com Subject: Re: zill-ipv6wg-zone-prefixlen-00 comments In-Reply-To: Your message of "Thu, 06 Mar 2003 13:46:43 +0200." <3E673523.4010707@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Mar 2003 23:18:33 -0500 Message-Id: <20030316041833.7131F7B87@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3E673523.4010707@kolumbus.fi>, Jari Arkko writes: > >I have a comment on the Zill draft as well as the Bellovin >draft. The Zill draft lacks instructions for the host on >what it should *do* with the information it receives. There's certainly no reason that my behavioral description couldn't be copied into Zill's draft. My concern about that draft, apart from Pekka's comments (and I agree with them), is that I think that the Prefix Information option is getting overloaded. Zill's draft shows four different flags -- what are the interactions between those flags? Are all 16 combinations of them legal? (I confess that I don't know what the R flag is, nor have I been able to find its definition in a quick grep through the RFC and drafts directories.) The Router Renumbering RFC might have to be updated to cover either draft. But draft-zill is certainly simpler than mine, and I have no objection to it being adopted. >The Bellovin draft, however, describes this in its >Section 2.3. I'm fine with that description. However, >I worry about one paragraph: > > In their default configuration, devices MUST NOT accept packets from > any non-link-local prefixes until they have received suitable > advertisements. However, there MAY be a configuration option to > permit acceptance of packets with the current link's prefix. > >If this text is to be taken literally, it would imply that >a host that supports this extension could never communicate >outside the link if the router doesn't support the same extension. >I'm assuming this only applies *if* the use of the advertisements >has been configured on? Actually, I meant what I said, though I've changed the text to read In their default configuration, devices that use this option... If your IPv6 light bulb doesn't have any better access controls than this, and if your router doesn't support this option -- then yes, that light bulb shouldn't talk off-link; it has no other way of knowing who's authorized to turn it on or off. > >And then I have some higher-level questions. Steven says himself >in the draft that its an open question whether such an extension >should exist. I have a few related questions. One question is why >this would have to be done by the nodes, wouldn't it be simpler >to do this in the routers (acting also as firewalls)? Note that >to use the extension, you'd have to configure the routers anyway. >In this case the argument about the hardness of filter configuration >on a toaster isn't very good. The problem with doing the filtering in the router is that the option then applies to all nodes behind that router, even if they have better security mechanisms. I may want this mechanism to apply to most of my hosts, but not to the hosts that run ssh servers. Or perhaps the unprotected hosts are my incoming mail gateways. > >Secondly, I know you Steven have worked on distributed firewalls. >Do you think we should have a very simple mechanism for filtering >as a part of neighbor discovery, a more powerful but also more >complex mechanism running at higher layers, or both? > I think that configuration of a real distributed firewall is a much more complex question, and not something I want to do on the fly in this working group. Furthermore, I very much don't want it to be router-based -- my paper points out that first, a lot of the benefit is for complex topologies, when you don't have a trusted perimeter router. Furthermore, my design relies heavily on ipsec and ipsec certificates. That's much more than I want to put into a router advertisement message. Should there be this sort of simplistic filtering based on router behavior? I'm not certain. But there seemed to be a feeling in the working group that that was one of the benefits of site-local was the built-in access control. We can't easily carry it further (i.e., put more general ACLs in the messages) without resorting to lots of reliable multicast groups on each link. I don't think I want to go there. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) -------------------------------------------------------------------- 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 Mar 16 03:47:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GBlZ7f026911; Sun, 16 Mar 2003 03:47:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2GBlZ4m026910; Sun, 16 Mar 2003 03:47:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GBlW7f026903 for ; Sun, 16 Mar 2003 03:47:32 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2GBlfcU005296 for ; Sun, 16 Mar 2003 03:47:41 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11183 for ; Sun, 16 Mar 2003 03:47:34 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 10:08:11 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Sun, 16 Mar 2003 10:08:10 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP; Sun, 16 Mar 2003 10:08:10 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay11.sun.com with ESMTP; Sun, 16 Mar 2003 10:08:08 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2GA80wY019417; Sun, 16 Mar 2003 12:08:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2GA7vXe019413; Sun, 16 Mar 2003 12:07:57 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: dual stack & IPv6 on by default From: Mika Liljeberg To: "Bound, Jim" Cc: Sebastien Roy , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB1@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB1@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1047809277.13138.88.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Mar 2003 12:07:57 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, [The following quote concerns RFC3484 and destination address selection] > >An implementation can't really know that a destination address > >is unreachable, unless it does a route search and, failing to > >find one, proceeds to try to ND all routerless links as well. > >Is that what we should do? > > I think today this is the bottom line only answer. That's too bad, because it means that the DNS resolver would have do this for the whole candidate destination address list. That takes time. I would much prefer do a route search only. > But your mail thread makes me wonder if we need to do more and I think > so. RFC1122 clarified and corrected several small details in the IPv4 specifications. I think the node requirements spec could do the same for any fuzzy bits in the IPv6 specificatons. > But it would have to be in the context of ND. ND is a requirement to > use IPv6. I agree. This is just a detail that needs to be clarified somehow. > Feels like an edge that could be "do this if ND don't work"? No. It's a very specific case of "how to implement the following bit of next-hop determination" in a host with multiple network interfaces and how it relates to RFC3484 and destination address selection: If the Default Router List is empty, the sender assumes that the destination is on-link. Until there is a clear understanding, we are sticking with: If the route search fails, the sender assumes the destination is unreachable. I haven't seen comments from any other implementors. It would be very interesting to hear if you have solved this and how you implemented it. Thanks, MikaL -------------------------------------------------------------------- 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 Mar 16 03:58:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GBwM7f027061; Sun, 16 Mar 2003 03:58:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2GBwMwG027060; Sun, 16 Mar 2003 03:58:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GBwJ7f027053 for ; Sun, 16 Mar 2003 03:58:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2GBwRcU006525 for ; Sun, 16 Mar 2003 03:58:28 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17023 for ; Sun, 16 Mar 2003 04:58:22 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 10:17:28 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 10:17:24 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 10:17:24 Z Received: from c001.snv.cp.net ([209.228.32.139] [209.228.32.139]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 10:17:23 Z Received: (cpmta 28622 invoked from network); 16 Mar 2003 02:17:13 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 16 Mar 2003 02:17:13 -0800 X-Sent: 16 Mar 2003 10:17:13 GMT Message-Id: <00c601c2eba5$685be7e0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: , , Subject: Question about IPv6 Management Date: Sun, 16 Mar 2003 12:18:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01C2EBB6.293B1BB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C2EBB6.293B1BB0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I appologize, this is being possted to multiple WG's as it seems to = cross areas. Is there any information about the requirment changes in the Network = Management Systems (NMS) or Operations Support Systems (OSS) necesary to = support IPv6? I have looked at the various MIB RFC's and such, but can not find = anything more than you need bigger address support and some SNMPv2 = compliance. This seems too simple to me. Eric ------=_NextPart_000_00C3_01C2EBB6.293B1BB0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
I appologize, this is being possted to = multiple=20 WG's as it seems to cross areas.
 
Is there any information about the = requirment=20 changes in the Network Management Systems (NMS) or Operations=20 Support Systems (OSS) necesary to support IPv6?
 
I have looked at the various MIB RFC's and = such, but=20 can not find anything more than you need bigger address support and some = SNMPv2=20 compliance.
 
This seems too simple to me.
 
 Eric
------=_NextPart_000_00C3_01C2EBB6.293B1BB0-- -------------------------------------------------------------------- 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 Mar 16 04:46:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GCkQ7f027604; Sun, 16 Mar 2003 04:46:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2GCkQ0B027603; Sun, 16 Mar 2003 04:46:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GCkN7f027596 for ; Sun, 16 Mar 2003 04:46:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2GCkWcU013322 for ; Sun, 16 Mar 2003 04:46:32 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15106 for ; Sun, 16 Mar 2003 05:46:25 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 12:14:25 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 12:14:03 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 12:14:03 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 12:14:02 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2GCDxW22401 for ; Sun, 16 Mar 2003 14:13:59 +0200 Date: Sun, 16 Mar 2003 14:13:59 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: chakrabarti-ipv6-addrselect-api-00 comments Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, A few comments on the address selection API draft. non-editorial: -------------- 6. Security Considerations This document conforms to the same security implications as specified in IPv6 Basic Socket API [2] document. It is also recommended that the applications set IPV6_V6ONLY IP level socket option to permit the nodes to not process IPv4 packets as IPv4 Mapped addresses. ==> even if I kinda agree with the last sentence, it seems to me to be a bit farfetched to be mentioned in this spec? - Is there a need for "validation" functions to go with these preferences such as functions that check whether an address is a temporary address? ==> perhaps validation functions would be nice, but generally speaking, it is not possible to, for certainty, to ensure what an address is or isn't? ==> Please clarify whether you meant a macro like "IN6_IS_ADDR_LOOPBACK" or something "verify whether this address assigned on the node was of type X"? mostly editorial: ----------------- Expires: August, 2003 Samita Chakrabarti Sun Microsystems, Inc. Julien Laganier Sun Microsystems, Inc. LIP / ENS-Lyon February, 2003 ==> a typo with affilications I assume, extra Sun? IPv6 Socket API for source address selection draft-chakrabarti-ipv6-addrselect-api-00.txt ==> uppercase words INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 ==> s/Feb., 2003/Feb 2003/ should be enough. 4. Changes to the protocol-independent nodename translation Section 8 of Default Address Selction [1] document indicates about ==> s/Selc/Selec/ 5. IPv4-Mapped IPv6 Addresses IPv4-Mapped IPv6 addresses are not supported for setting preference on home, care-of-address, CGA, non-CGA, public or privacy auto- configured addresses as source addresses. Because they are all pure IPv6 addresses. ==> reword the last sentence to mix better with the rest. ==> isn't it "IPv4-mapped" with small m? [2] R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens, "Basic Socket Interface Extensions for IPv6", draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002. ==> surnames first, initial next in the ref author lists -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 16 10:10:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIAm7f029196; Sun, 16 Mar 2003 10:10:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2GIAmRA029195; Sun, 16 Mar 2003 10:10:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIAi7f029188 for ; Sun, 16 Mar 2003 10:10:44 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIAjP05657; Sun, 16 Mar 2003 19:10:45 +0100 (MET) Date: Sun, 16 Mar 2003 19:06:47 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt To: Jun-ichiro itojun Hagino Cc: Erik Nordmark , ettikan.kandasamy.karuppiah@intel.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, mrw@windriver.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >RFC 3258 uses the term "shared-unicast address" for what you seem to be > calling >"pseudo-anycast". I wonder if it makes sense using this existing > term instead >of creating a new one. > > if "shared-unicast address" is more common, i'm happy to use that term. I don't know if that term is widely used, but I think it makes sense defining it in the document and using it. > i'll update the draft to refer RFC3258 and make necessary adjustments. > i'm not sure if i should keep references to mohta-san's draft. I think it's fine to keep the reference as long as you explain the salient issues. > i guess title of section 3 was vague - "current proposals" tries to mean > "current proposals made for IPv6", like RFC2373 limitation for IPv6 > anycast address assignment. therefore, 3.3 talks about restriction > imposed by RFC2373, which is applicable to IPv6 only. > i'll update title of section 3 to be more clear, and make sure to > remove any IPv4 topic from section 3. But RFC 2373 is more than a proposal - it is the IPv6 addressing architecture. Even if some folks might want to change it I think it can be confusing to calling it a proposal - the "current state of IPv6 anycast architecture" might be more accurate since it indicates potential future changes without treating it as merely a proposal. > the paragraph tries to say: > - if we use predefined site-local anycast address, the propagation of > host route (/128) would be limited within the site, therefore it may > be permissible (depending on the routing table size of the site) or they might even be aggregated at an IGP area boundary... > - if we use predefined global anycast address, host route needs to be > carried worldwide and we will see problems like you mentioned above. > > how should i word it for clarity? Point out in section 1 that anycast addresses have route scalaing issues. If anycast addresses are drawn from the unicast address space (as is the case in IPv6 and the IPv4 DNS anycast) the routing scaling impact can potentially be limited by aggregating the anycast addresses as part of the regular unicast routing prefixes. But this aggregation can only be applied when all members in the anycast group remaing within the piece of toplogy whose routes get aggregated. For instance having an anycast address where all the members belong to one ISP means it the anycast address can be drawn from the ISPs address space and be aggregated at the ISP boundary with no effect on route scaling outside that domain. But having e.g. anycast groups with members across the whole Internet will have effect on the size of the routing tables globally. Does that capture what you want to say? > >I don't see any text in section 4.1 in 2181 that recommends changing > >anything on the client. In fact section 4 and 4.1 is how to make > >servers work with clients that do verify the source address of the reply. > >Thus I can't see how you come to this conclusion. > > quoting RFC2181: > >> will be able to use it for further queries. Servers configured in > >> such a way that not all their addresses are equally reachable from > >> all potential clients need take particular care when responding to <--- > >> queries sent to anycast, multicast, or similar, addresses. <--- > from the above text, it is clear that client should/can not check the > source address of the reply in the above case. Your notion of clarity seems quite different than mine. Section 4 in 2181 is about server behavior with recommendations on how to make servers work with a large range of different client behavior. But that doesn't mean that you can infer recommended or required client behavior from that section. > routers will know that the host is authorized to inject a route to > the routing system, by the fact that it knows the shared secret > used by the routing protocol (if the route is advertised with proper > authentication encapsulation/extension header, it is authorized). > do i need to be more clear on such trivial thing? if so, how? But if the host knows the shared secret used by the routing protocol it can inject any route (e.g. default or some other prefix). For anycast presumably one would want to restrict the host to only inject a particular host route. 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 Sun Mar 16 10:42:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIg87f000490; Sun, 16 Mar 2003 10:42:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2GIg7sw000488; Sun, 16 Mar 2003 10:42:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIfu7f000458 for ; Sun, 16 Mar 2003 10:41:56 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIg1P07488; Sun, 16 Mar 2003 19:42:01 +0100 (MET) Date: Sun, 16 Mar 2003 19:38:03 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] To: Pekka Savola Cc: Tim Chown , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Actually, the security properties of RA-piggybacking solutions are roughly > on the same level as with DHCP and friends, not to mention general > connectivity. There might be a difference in that the DHC WG is supposedly working on deployable security for DHCP. But then again, we have SEND which might help secure the RAs. So "roughly the same" might capture both the situation today and in the future. 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 Sun Mar 16 10:42:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIgB7f000499; Sun, 16 Mar 2003 10:42:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2GIgANQ000495; Sun, 16 Mar 2003 10:42:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIfv7f000463 for ; Sun, 16 Mar 2003 10:41:58 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIftP07472; Sun, 16 Mar 2003 19:41:56 +0100 (MET) Date: Sun, 16 Mar 2003 19:37:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Sebastien Roy Cc: "Bound, Jim" , Mika Liljeberg , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If you don't have a route to the destination, why try to reach it > on-link just in case the destination might happen to be on-link? Is > there a situation where this would be useful? > Back when the ND spec was written the idea was that if two nodes can communicate on a link (e.g. using global addresses) it would be nice if they could continue to communicate even if the router(s) to the link disappear. I don't recall if there were any assumptions about the relative lifetime of the addresses they are configured (using stateless, dhcp, or manual) and the on-link prefixes advertised by the routers. But given that the ND spec allows a configuration where the routers don't advertise on-link prefixes (which causes initial packets to go through the router and then be redirected to the on-link destination) it would seem useful to be able to communicate after the router has gone away. 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 Sun Mar 16 10:42:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIgM7f000512; Sun, 16 Mar 2003 10:42:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2GIgLlD000509; Sun, 16 Mar 2003 10:42:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2GIg77f000489 for ; Sun, 16 Mar 2003 10:42:08 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIg6P07492; Sun, 16 Mar 2003 19:42:06 +0100 (MET) Date: Sun, 16 Mar 2003 19:38:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Sebastien Roy Cc: "Bound, Jim" , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That's a really good question. I'm not sure what would be the best way > to address this. What we're saying in this draft is that operational > experience has shown that this part of ND could be problematic in some > circumstances. Does ND need to be changed as a result? Probably not. > There are no MUST's surrounding that bit of ND. As implementors, we're > free to interpret the spec in a sane mannor. With this draft, we're > pointing out reasons why implementors may want to be careful with that > part of ND. There is informational value in this alone without having > to muck with the ND spec itself. A possible way to approach this problem would be to make the choice between A and AAAA be a function of whether there is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). That way you don't have to tweak ND. But you do end up with some having e.g. getaddrinfo() check with the kernel. I think getaddrinfo() needs to already do some checks in order to implement the default address selection document. > If you don't have a route to the destination, why try to reach it > on-link just in case the destination might happen to be on-link? Is > there a situation where this would be useful? If you have two nodes communicating on a link and the router dies for long enough time it seems useful to be able to continue to communicate. Of course, the communication will fail once the addresses become invalid but that might take a long time. 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 Sun Mar 16 16:49:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H0n17f002584; Sun, 16 Mar 2003 16:49:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H0n053002583; Sun, 16 Mar 2003 16:49:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H0mu7f002576 for ; Sun, 16 Mar 2003 16:48:56 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H0n5jO020844 for ; Sun, 16 Mar 2003 16:49:05 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12875 for ; Sun, 16 Mar 2003 16:48:59 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 00:48:56 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 00:48:55 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 00:48:54 Z Received: from hoemail1.firewall.lucent.com ([192.11.226.161] [192.11.226.161]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 00:48:52 Z Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2H0mm718040 for ; Sun, 16 Mar 2003 19:48:48 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 01:48:34 +0100 Message-Id: <7D5D48D2CAA3D84C813F5B154F43B155012719C2@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: EricLKlein , v6ops@ops.ietf.org, eos@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: RE: Question about IPv6 Management Date: Mon, 17 Mar 2003 01:48:32 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC1E.EEDF5846" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2EC1E.EEDF5846 Content-Type: text/plain; charset="windows-1255" We have been defining a number of things so that IP (or better Internet) addresses can be represented in an IPversion neutral matter. See for example RFC3291. We are checking all MIB modules to be IPv4 and IPv6 capable (unless a module is for one specific IP version). We have defined TCs so that we also have IPv6 transport addresses so that SNMP can go over IPv6. See RFC3419 Various MIB modules are being reqorked in the IPv6 WG Hope this helps Thanks,Bert -----Original Message----- From: EricLKlein [mailto:ericlklein@softhome.net] Sent: zondag 16 maart 2003 11:19 To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com Subject: Question about IPv6 Management I appologize, this is being possted to multiple WG's as it seems to cross areas. Is there any information about the requirment changes in the Network Management Systems (NMS) or Operations Support Systems (OSS) necesary to support IPv6? I have looked at the various MIB RFC's and such, but can not find anything more than you need bigger address support and some SNMPv2 compliance. This seems too simple to me. Eric ------_=_NextPart_001_01C2EC1E.EEDF5846 Content-Type: text/html; charset="windows-1255"
We have been defining a number of things so that IP (or better Internet) addresses
can be represented in an IPversion neutral matter. See for example RFC3291.
 
We are checking all MIB modules to be IPv4 and IPv6 capable (unless a module
is for one specific IP version).
 
We have defined TCs so that we also have IPv6 transport addresses so that
SNMP can go over IPv6. See RFC3419
 
Various MIB modules are being reqorked in the IPv6 WG
 
Hope this helps

Thanks,Bert

-----Original Message-----
From: EricLKlein [mailto:ericlklein@softhome.net]
Sent: zondag 16 maart 2003 11:19
To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com
Subject: Question about IPv6 Management

I appologize, this is being possted to multiple WG's as it seems to cross areas.
 
Is there any information about the requirment changes in the Network Management Systems (NMS) or Operations Support Systems (OSS) necesary to support IPv6?
 
I have looked at the various MIB RFC's and such, but can not find anything more than you need bigger address support and some SNMPv2 compliance.
 
This seems too simple to me.
 
 Eric
------_=_NextPart_001_01C2EC1E.EEDF5846-- -------------------------------------------------------------------- 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 Mar 16 21:26:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H5QR7f004883; Sun, 16 Mar 2003 21:26:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H5QRMR004882; Sun, 16 Mar 2003 21:26:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H5QN7f004875 for ; Sun, 16 Mar 2003 21:26:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H5QScU004165 for ; Sun, 16 Mar 2003 21:26:32 -0800 (PST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04645 for ; Sun, 16 Mar 2003 22:26:23 -0700 (MST) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HBV005OBOFYNL@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 22:26:23 -0700 (MST) Received: from sun.com ([130.129.139.210]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HBV00EUSOFX3F@mail.sun.net> for ipng@sunroof.eng.sun.com; Sun, 16 Mar 2003 22:26:22 -0700 (MST) Date: Sun, 16 Mar 2003 21:26:21 -0800 From: Alain Durand Subject: Re: dual stack & IPv6 on by default In-reply-to: To: Erik Nordmark Cc: Sebastien Roy , "Bound, Jim" , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.551) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sunday, March 16, 2003, at 10:38 AM, Erik Nordmark wrote: >> That's a really good question. I'm not sure what would be the best >> way >> to address this. What we're saying in this draft is that operational >> experience has shown that this part of ND could be problematic in some >> circumstances. Does ND need to be changed as a result? Probably not. >> There are no MUST's surrounding that bit of ND. As implementors, >> we're >> free to interpret the spec in a sane mannor. With this draft, we're >> pointing out reasons why implementors may want to be careful with that >> part of ND. There is informational value in this alone without having >> to muck with the ND spec itself. > > A possible way to approach this problem would be to make > the choice between A and AAAA be a function of whether there > is one or more IPv6 route off-link (or at least one IPv6 router > sending RAs). > > That way you don't have to tweak ND. But you do end up with some > having e.g. getaddrinfo() check with the kernel. I think getaddrinfo() > needs to already do some checks in order to implement the default > address > selection document. What is the benefit of doing so versus doing the change in ndpd? > >> If you don't have a route to the destination, why try to reach it >> on-link just in case the destination might happen to be on-link? Is >> there a situation where this would be useful? > > If you have two nodes communicating on a link and the router > dies for long enough time it seems useful to be able to > continue to communicate. In that case, it make sense to maintain the local subnet route but remove the default route. Destination on the local subnet will still be reachable, other further destination won't and we will not try them. This can be done in ndpd. > Of course, the communication will fail > once the addresses become invalid but that might take a long time. > > 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 Sun Mar 16 21:30:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H5UG7f004922; Sun, 16 Mar 2003 21:30:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H5UGPi004920; Sun, 16 Mar 2003 21:30:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H5UC7f004913 for ; Sun, 16 Mar 2003 21:30:13 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H5ULjO007622 for ; Sun, 16 Mar 2003 21:30:21 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23721 for ; Sun, 16 Mar 2003 22:30:16 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 05:30:15 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 05:30:10 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 05:30:09 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 05:30:09 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 675F04FE7; Mon, 17 Mar 2003 00:30:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 00:30:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dual stack & IPv6 on by default Date: Mon, 17 Mar 2003 00:30:05 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCD3@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dual stack & IPv6 on by default Thread-Index: AcLro9BxlDThWtqyS/SqBhqMiYGz4gAohoTw From: "Bound, Jim" To: "Mika Liljeberg" Cc: "Sebastien Roy" , "Ronald van der Pol" , "Alain Durand" , , , X-OriginalArrivalTime: 17 Mar 2003 05:30:06.0279 (UTC) FILETIME=[449CD570:01C2EC46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2H5UD7f004914 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mika, > > I think today this is the bottom line only answer. > > That's too bad, because it means that the DNS resolver would > have do this for the whole candidate destination address > list. That takes time. I would much prefer do a route search only. I agree with you and I still have reservations about source address selection for those performance reasons. > > > But your mail thread makes me wonder if we need to do more > and I think > > so. > > RFC1122 clarified and corrected several small details in the > IPv4 specifications. I think the node requirements spec could > do the same for any fuzzy bits in the IPv6 specificatons. > > > But it would have to be in the context of ND. ND is a > requirement to > > use IPv6. > > I agree. This is just a detail that needs to be clarified somehow. Yes. I can be done with new ICMP types or options. > > > Feels like an edge that could be "do this if ND don't work"? > > No. It's a very specific case of "how to implement the > following bit of next-hop determination" in a host with > multiple network interfaces and how it relates to RFC3484 and > destination address selection: > > If the Default Router List is empty, > the sender assumes that the destination is on-link. > > Until there is a clear understanding, we are sticking with: > > If the route search fails, > the sender assumes the destination is unreachable. > > I haven't seen comments from any other implementors. It would > be very interesting to hear if you have solved this and how > you implemented it. Agreed. Others need to jump in here. I think we have a hole. /jim > > Thanks, > > MikaL > > -------------------------------------------------------------------- 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 Mar 16 22:09:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6987f005365; Sun, 16 Mar 2003 22:09:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H698vo005364; Sun, 16 Mar 2003 22:09:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6947f005356 for ; Sun, 16 Mar 2003 22:09:04 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H69DcU011833 for ; Sun, 16 Mar 2003 22:09:13 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA15902 for ; Sun, 16 Mar 2003 22:09:05 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:07:10 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:07:01 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:07:01 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:06:31 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA19449; Mon, 17 Mar 2003 06:06:21 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA25798; Mon, 17 Mar 2003 06:06:20 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2H66KM24475; Mon, 17 Mar 2003 06:06:20 GMT Date: Mon, 17 Mar 2003 06:06:20 +0000 From: Tim Chown To: Johan Ihren Cc: Pekka Savola , dns op wg , ipng@sunroof.eng.sun.com Subject: Re: dns discovery for agenda? [Re: chairs and charter] Message-Id: <20030317060620.GA24236@login.ecs.soton.ac.uk> Mail-Followup-To: Johan Ihren , Pekka Savola , dns op wg , ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Mar 16, 2003 at 10:10:39PM +0100, Johan Ihren wrote: > That you're not interested in configuring ntp, foo and bar is fine. > But that is in no way an argument for a multitude of discovery > mechanisms. I still think that *one* generic discovery mechanism is > very much better than several. > > Much better that you just configure your client not to import the > stuff you don't care about than inventing more mechanisms to support > every form of granularity that people can invent. > > Let's keep it simple. Hi Johan, I agree with the keep it simple princple in general, but in this case I'm not convincved. DNS is a special case, as Pekka explained. I think that, for example, advertising DNS by RA's in IPv6 offers a veru useful "missing piece" in the stateless autoconfiguration puzzle. To require the presence of DHCPv6 for DNS discovery in IPv6 seems wrong. I have no objection to it as *a* method, but in the scenario of my home network I'd be quite happy to run without statelessly configuring clients needing to use DHCP to get the DNS info. I think many people accept that the well-known site-local method will die because of the issues with site-locals, thus leaving only DHCPv6 unless something like RA piggybacks is defined for the stateless scenario. It would be interesting to review discovery methods in different protocols (including transition protocols), as a variety of methods are already used including well-known (site-local) addresses, link-local multicast, well-known names, DHCPv6, SLP, anycast, etc. The more we have, the more that needs to be supported (which in itself becomes an argument to keep the stateless picture simpler by not requiring DHCPv6 presence). 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 Sun Mar 16 22:09:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H69n7f005386; Sun, 16 Mar 2003 22:09:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H69nk2005385; Sun, 16 Mar 2003 22:09:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H69j7f005378 for ; Sun, 16 Mar 2003 22:09:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H69scU011931 for ; Sun, 16 Mar 2003 22:09:54 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16186 for ; Sun, 16 Mar 2003 22:09:48 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:09:48 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:09:47 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:09:47 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:09:46 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA19492 for ; Mon, 17 Mar 2003 06:09:43 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA06614 for ; Mon, 17 Mar 2003 06:09:43 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2H69hE24487 for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:09:43 GMT Date: Mon, 17 Mar 2003 06:09:43 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] Message-Id: <20030317060943.GB24236@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Mar 16, 2003 at 07:38:03PM +0100, Erik Nordmark wrote: > > Actually, the security properties of RA-piggybacking solutions are roughly > > on the same level as with DHCP and friends, not to mention general > > connectivity. > > There might be a difference in that the DHC WG is supposedly > working on deployable security for DHCP. > But then again, we have SEND which might help secure the RAs. > > So "roughly the same" might capture both the situation today and in the future. OK, well, at present there seems only mild interest at best in this, even by the original RA method author :) But I'd like to see one more push made on the concept as it is useful for the stateless scenario (like Pekka, I visit many IPv6 networks and it is a missing piece - of course in part because very few people have running DHCPv6, but should they have to deploy it just for DNS?). 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 Sun Mar 16 22:48:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6mO7f006168; Sun, 16 Mar 2003 22:48:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H6mO1L006167; Sun, 16 Mar 2003 22:48:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6mK7f006160 for ; Sun, 16 Mar 2003 22:48:20 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H6mTjO021388 for ; Sun, 16 Mar 2003 22:48:29 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03169 for ; Sun, 16 Mar 2003 22:48:24 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:48:09 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:48:08 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:48:08 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:48:08 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA19878; Mon, 17 Mar 2003 06:48:05 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id GAA09301; Mon, 17 Mar 2003 06:48:04 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2H6m4L24705; Mon, 17 Mar 2003 06:48:04 GMT Date: Mon, 17 Mar 2003 06:48:04 +0000 From: Tim Chown To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default Message-Id: <20030317064804.GG24236@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Mar 16, 2003 at 07:38:09PM +0100, Erik Nordmark wrote: > > A possible way to approach this problem would be to make > the choice between A and AAAA be a function of whether there > is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). Note this cuts both ways. I've been in dual-protocol networks where IPv4 has been down and IPv6 up, so we ought to consider the general case of availability of connectivity off-link for either protocol. (But I do appreciate the issues here is - I think - what to do when deploying an IPv6 enabled host which receives AAAA responses in an IPv4-only network) A not-uncommon enterprise deployment method for dual-protocol now is to have a parallel IPv6 infrastructure with a separate off-site IPv6 link, such that IPv6 is routed within the site using (for example) BSD routers with RA's for subnets injected into the v4 VLANs (if your BSD box can VLAN-tag on a single interface, very few cables may be needed :). Thus the router giving connectivity off each subnet is different (in one case, the "smart" L2/L3 VLAN switching equipment, in the other, PC-based routers) , and either could fail. Such a deployment method is a short-term one until Cisco, Alcatel, etc offer v6 L2/L3 functionality as exists for v4 now. Most dual-protocol networks will probably in the medium-term fate-share IPv4 and IPv6, so the distinction will then be somewhat moot. 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 Sun Mar 16 22:50:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6oM7f006218; Sun, 16 Mar 2003 22:50:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H6oMbS006217; Sun, 16 Mar 2003 22:50:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6oI7f006210 for ; Sun, 16 Mar 2003 22:50:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H6oRjO021793 for ; Sun, 16 Mar 2003 22:50:27 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04083 for ; Sun, 16 Mar 2003 22:50:21 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:50:21 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:50:20 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:50:20 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:50:18 Z Received: from localhost (wl-140-223.wireless.ietf56.ietf.org [130.129.140.223]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 353AB15252; Mon, 17 Mar 2003 15:50:25 +0900 (JST) Date: Mon, 17 Mar 2003 15:50:42 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: comments on sl-impact-02 In-Reply-To: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> References: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 186 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 15 Mar 2003 07:40:45 -0500, >>>>> Margaret Wasserman said: >> 3.1.2.1 Problems for All Site-Border Nodes >> >> Some people have commented that the same problems exist for link- >> local addresses, but this is not entirely true. Link-local >> addresses can use an existing identifier, the interface name or >> number, as their qualifier, while site-local addresses require the >> configuration of an artificial zone ID. >> >> Technically, this is not really true since links are larger scope than >> interfaces. > Does anyone have an implementation today that has any special > handling for multi-interface links? If you want to send a > packet to a LL address, are you supposed to send it out all of > the interfaces for that link, or only one of them (if so, which > one)? Though we've not implemented multi-interface links, I'd implemented this function so that only one of the interfaces should be the outgoing link for each link-local destination. >> In general, link-local addresses will only be used for >> specialized purposes or on single-link networks where they can be >> treated exactly like global addresses. >> >> I agree about the DNS issue. >> >> But I, as an operator of IPv6 networks, often use ping or ssh on a router >> (i.e., a multi-link nodes) with disambiguating an appropriate link. >> Is such usage included in the "general" use? > I don't know... What are you doing this for? If you are doing it > to configure and test a router, then I would say 'no', this isn't > general use. We use this for management purposes, especially when we have a routing trouble. A typical case is that - we have a point-to-point link where we only assign link-local addresses. - a routing trouble happens around one side of the router, and we cannot send packets beyond the router. - to diagnose this, we first try to ping the router using its link-local address. - if the router is still alive, we'll then try to log in to the router (via ssh or telnet) using the link-local address. I guess this is NOT a "general use" according to your reply, and it's okay since this is a matter of wording definition in the draft. But I'd like the draft to make what "specialized purposes" means clearer so that the reader can easily understand the above usage is a special case. >> 3.1.2.2 Problems for Site-Border Routers >> >> All IPv6 routers will need to check >> all forwarded packets to determine if either the source or >> destination is link-local. If so, the packet will be discarded and >> an appropriate ICMP error message will be generated. >> >> The procedure cannot be that simple. First, (again) since links are >> larger than interfaces, it is possible for a router to forward a >> packet with a link-local source or destination from an interface to >> another one. Even in the default configuration where there is a >> one-to-one mapping between links and interfaces, a router can receive >> a packet with a link-local destination from an interface and forward >> it back to the same interface. > We definitely need to discuss this "links are larger than interfaces" > concept... This will probably lead to link-local addresses having > more of the problems associated with site-local addresses than I > originally thought. I partly agree. Unfortunately, however, the designer of this model is Steve, who is out for a long sabbatical... Besides, please note that even if we adopt the "links is equal to interfaces" model, the issue raised in this section still exists as I said above. >> For example, this mechanism would not work properly when a local >> caching resolver is used. In this common configuration, ... >> >> What exactly do you mean by "a local caching resolver"? Do you mean, >> e.g. a BIND DNS caching server running on the same node of the >> resolver? If so, I don't think this is not a so common >> configuration. > I'll have to ask whoever sent me the text :-). I think it was > Rob Austein. Okay, btw, I actually meant "I don't think this is a so common configuration," though you seemed to read this correctly:-) >> Application user-interfaces will need to support the inclusion of a >> zone ID whenever an IP address is entered by the user, >> >> I'm not 100% sure what "Application user-interfaces" means here. >> Scope-aware getaddrinfo() can provide a transparent user-interface to >> specify zone ID, regardless of the scope type. > Sorry, I don't understand your statement, either. > If the application has a dialogue box in which the customer can specify > an IP address (instead of a host name), the UI will need to allow the > user to enter a zone ID, as well. That isn't true in IPv4, but it will > be needed in IPv6. That's correct. What I'm trying to say is that the dialog box can just accept the format like "fec0::1%X", as a string, using getaddrinfo() as a backend. Then the UI itself does not need to care about a "zone ID". Of course, you can call this "Application user-interfaces will need to support the inclusion of a zone ID". >> and >> applications will have to add a default zone ID to IP addresses >> when one is not provided. >> >> This is not necessarily true, or at least an implementation dependent. >> In fact, implementation in fact supports the ability to set a default >> zone ID in the kernel, so that applications need not be scope-aware. > Do you set a default zone ID for each scope? Yes. More accurately, we allow the administrator to specify the default zone ID for each scope. > So, there would be a > default link and a default site? Again, yes. However, a node is not multi-scoped for scopes larger than links (or subnets for multicasts) by default according to the default configuration described in the scoping arch draft. So, the administrator does not have to set the default site zone in the default configuration. >> 4.3 Networks behind NATs >> >> This includes IPv6 sites that are connected to the IPv4 >> Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT], >> as well as IPv6 sites that may be connected to an IPv6 Internet >> using IPv6-to-IPv6 NAT. >> >> I don't understand the intended usage about sites using IPv6-to-IPv6 >> NAT. Could you be more specific please? > We don't have any plans to provide portable addresses in IPv6, so > people will end-up deploying IPv6<->IPv6 NAT in order to gain address > portability/ISP-independence for their internal addresses. I don't > like this, but I consider it a fact of life. > When they do deploy IPv6<->IPv6 NAT, it is important to have a set > of readily-identifiable non-global addresses to use behind the NAT, > so that we can prefer IPv4 global addresses to local IPv6 addresses > (and vice versa). I am suggesting that site-local addresses be used > for this purpose. I see your points. Then please make this clear in this section. >> 12 Appendix A: "Limited Use" Proposal >> >> So, the author of this document recommends that IPv6 site-local >> addresses be reserved for use on isolated, single-site networks or >> behind NATs (either IPv4-to-IPv6 or IPv6-to-IPv6 NATs). >> >> Do you actually mean IPv6-to-IPv4 NAT (not IPv4-to-IPv6)? > I mean both NAT-PT (IPv4<->IPv6) and IPv6<->IPv6 NAT (translating > internal IPv6 addresses to external IPv6 addresses). I see, so you mean "between IPv4 and IPv6", not "from IPv4 to IPv6". Then I'd like the former notation than the latter. Also, you use a different notation in Section 4.3: This includes IPv6 sites that are connected to the IPv4 Internet via an IPv6-to-IPv4 NAT solutions, such as NAT-PT [NATPT], ^^^^^^^^^^^^ which is one of the source of confusion (for me). If you intend the same mechanism (e.g. NAT-PT) both in Section 4.3 and in Section 12, please be consistent on the notation. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 16 22:54:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6sU7f006495; Sun, 16 Mar 2003 22:54:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H6sUJm006494; Sun, 16 Mar 2003 22:54:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6sR7f006486 for ; Sun, 16 Mar 2003 22:54:27 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H6sajO022653 for ; Sun, 16 Mar 2003 22:54:36 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12577 for ; Sun, 16 Mar 2003 22:54:30 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:54:30 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:54:29 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:54:29 Z Received: from c001.snv.cp.net ([209.228.32.115] [209.228.32.115]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:54:29 Z Received: (cpmta 6200 invoked from network); 16 Mar 2003 22:54:27 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.115) with SMTP; 16 Mar 2003 22:54:27 -0800 X-Sent: 17 Mar 2003 06:54:27 GMT Message-Id: <002201c2ec52$3f61e990$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: "Wijnen, Bert \(Bert\)" , , , References: <7D5D48D2CAA3D84C813F5B154F43B155012719C2@nl0006exch001u.nl.lucent.com> Subject: Re: Question about IPv6 Management Date: Mon, 17 Mar 2003 08:55:48 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C2EC63.00F57940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C2EC63.00F57940 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Thank you. I have been reading: RFC 2452 IP v6 MIB for the TCP RFC 2454 IP v6 MIB for the UDP RFC 2466 MIB for IP v6 ICMP=20 But didn't see anything more detailed. Thanks for the information. Eric ----- Original Message -----=20 From: Wijnen, Bert (Bert)=20 To: EricLKlein ; v6ops@ops.ietf.org ; eos@ops.ietf.org ; = ipng@sunroof.eng.sun.com=20 Sent: Monday, March 17, 2003 2:48 AM Subject: RE: Question about IPv6 Management We have been defining a number of things so that IP (or better = Internet) addresses can be represented in an IPversion neutral matter. See for example = RFC3291. We are checking all MIB modules to be IPv4 and IPv6 capable (unless a = module is for one specific IP version).=20 We have defined TCs so that we also have IPv6 transport addresses so = that=20 SNMP can go over IPv6. See RFC3419 Various MIB modules are being reqorked in the IPv6 WG=20 Hope this helps Thanks,Bert=20 -----Original Message----- From: EricLKlein [mailto:ericlklein@softhome.net] Sent: zondag 16 maart 2003 11:19 To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com Subject: Question about IPv6 Management I appologize, this is being possted to multiple WG's as it seems to = cross areas. Is there any information about the requirment changes in the Network = Management Systems (NMS) or Operations Support Systems (OSS) necesary to = support IPv6? I have looked at the various MIB RFC's and such, but can not find = anything more than you need bigger address support and some SNMPv2 = compliance. This seems too simple to me. Eric ------=_NextPart_000_001F_01C2EC63.00F57940 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Thank you. I have been = reading:

RFC 2452 IP = v6 MIB for=20 the TCP

RFC 2454 IP = v6 MIB for=20 the UDP

RFC=20 2466 MIB for IP v6 ICMP
 
But=20 didn't see anything more detailed. Thanks for the = information.
Eric
----- Original Message -----
From:=20 Wijnen, Bert=20 (Bert)
To: EricLKlein ; v6ops@ops.ietf.org ; eos@ops.ietf.org ;=20 ipng@sunroof.eng.sun.com =
Sent: Monday, March 17, 2003 = 2:48=20 AM
Subject: RE: Question about = IPv6=20 Management

We=20 have been defining a number of things so that IP (or better Internet)=20 addresses
can=20 be represented in an IPversion neutral matter. See for example=20 RFC3291.
 
We=20 are checking all MIB modules to be IPv4 and IPv6 capable (unless a=20 module
is=20 for one specific IP version).
 
We=20 have defined TCs so that we also have IPv6 transport addresses so that =
SNMP=20 can go over IPv6. See RFC3419
 
Various MIB modules are being reqorked in = the IPv6 WG=20
 
Hope=20 this helps

Thanks,Bert

-----Original Message-----
From: EricLKlein=20 [mailto:ericlklein@softhome.net]
Sent: zondag 16 maart = 2003=20 11:19
To: v6ops@ops.ietf.org; eos@ops.ietf.org;=20 ipng@sunroof.eng.sun.com
Subject: Question about IPv6=20 Management

I appologize, this is being possted = to multiple=20 WG's as it seems to cross areas.
 
Is there any information about the = requirment=20 changes in the Network Management Systems (NMS) or Operations=20 Support Systems (OSS) necesary to support = IPv6?
 
I have looked at the various MIB RFC's = and such,=20 but can not find anything more than you need bigger address support = and some=20 SNMPv2 compliance.
 
This seems too simple to me.
 
 Eric
------=_NextPart_000_001F_01C2EC63.00F57940-- -------------------------------------------------------------------- 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 Mar 16 22:56:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6uL7f006651; Sun, 16 Mar 2003 22:56:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H6uL2w006650; Sun, 16 Mar 2003 22:56:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H6uG7f006640 for ; Sun, 16 Mar 2003 22:56:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H6uPcU020590 for ; Sun, 16 Mar 2003 22:56:26 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA05692 for ; Sun, 16 Mar 2003 23:56:19 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:56:19 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:56:19 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:56:18 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 06:56:17 Z Received: from localhost (wl-140-223.wireless.ietf56.ietf.org [130.129.140.223]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 95F8015252; Mon, 17 Mar 2003 15:56:28 +0900 (JST) Date: Mon, 17 Mar 2003 15:56:45 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mika Liljeberg Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: comments on sl-impact-02 In-Reply-To: <1047738239.13132.52.camel@devil> References: <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> <1047738239.13132.52.camel@devil> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On 15 Mar 2003 16:24:00 +0200, >>>>> Mika Liljeberg said: >> > For example, this mechanism would not work properly when a local >> > caching resolver is used. In this common configuration, ... >> > >> >What exactly do you mean by "a local caching resolver"? Do you mean, >> >e.g. a BIND DNS caching server running on the same node of the >> >resolver? If so, I don't think this is a so common >> >configuration. >> >> I'll have to ask whoever sent me the text :-). I think it was >> Rob Austein. > It's not so unheard of to run a local copy of BIND for caching. (I corrected a typo in my original message.) I know, and I myself run a BIND caching server on my laptop, but my point is that "not so unheard" does not mean "common configuration". >> Do you set a default zone ID for each scope? So, there would be a >> default link and a default site? > I can't comment on the KAME implementation, but in general you can just > specify a default interface and read the default zone IDs for each scope > level from the scope table of that interface. Hmm, perhaps I was not clear in the reply to Margaret (I should have read the entire thread before replying to the first one...). We actually implemented this way; we support the ability to specify the "default interface." JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 16 23:03:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H73Q7f007113; Sun, 16 Mar 2003 23:03:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H73Q3I007112; Sun, 16 Mar 2003 23:03:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H73L7f007105 for ; Sun, 16 Mar 2003 23:03:22 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H73UcU022205 for ; Sun, 16 Mar 2003 23:03:30 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16883 for ; Sun, 16 Mar 2003 23:03:25 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:03:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:00:50 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:03:20 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:03:19 Z Received: from localhost (wl-140-223.wireless.ietf56.ietf.org [130.129.140.223]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D10E715252; Mon, 17 Mar 2003 16:03:29 +0900 (JST) Date: Mon, 17 Mar 2003 16:03:46 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: comments on sl-impact-02 In-Reply-To: <200303151615.h2FGFPNS024986@burp.tkv.asdf.org> References: <20030315160659.E167F791@starfruit.itojun.org> <200303151615.h2FGFPNS024986@burp.tkv.asdf.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 15 Mar 2003 18:15:25 +0200, >>>>> Markku Savela said: >> to be clear: for outgoing packet, that should be enough. for incoming >> packet, you will need to have a mapping table of >> interface id -> link id >> and translate id accordingly and use "fe80::1%linkX" as the identifier >> for the peer. > Such mapping is very simple: you just have each interface associated > array of scope id's (16). For incoming packet, you just complete the > source and destination addresses with: linkX = > interface-> scopes[scope_of_addr]. Works also for multicast > destinations, which may have almost any scope. Yes, that's exactly what our current implementation does (except the "fe80::1%linkX" notation). So, in some points, our implementation have already prepared for the "links are larger than interfaces" model. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 16 23:31:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H7VI7f007540; Sun, 16 Mar 2003 23:31:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H7VIuZ007539; Sun, 16 Mar 2003 23:31:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H7VD7f007532 for ; Sun, 16 Mar 2003 23:31:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H7VLjO028836 for ; Sun, 16 Mar 2003 23:31:21 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA02312 for ; Mon, 17 Mar 2003 00:31:15 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:31:14 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:30:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:30:44 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 07:30:43 Z Received: from localhost (wl-140-223.wireless.ietf56.ietf.org [130.129.140.223]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CF6B215252; Mon, 17 Mar 2003 16:30:53 +0900 (JST) Date: Mon, 17 Mar 2003 16:31:10 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mika Liljeberg Cc: "Bound, Jim" , Sebastien Roy , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default In-Reply-To: <1047809277.13138.88.camel@devil> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB1@tayexc13.americas.cpqcorp.net> <1047809277.13138.88.camel@devil> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On 16 Mar 2003 12:07:57 +0200, >>>>> Mika Liljeberg said: > No. It's a very specific case of "how to implement the following bit of > next-hop determination" in a host with multiple network interfaces and > how it relates to RFC3484 and destination address selection: > If the Default Router List is empty, > the sender assumes that the destination is on-link. > Until there is a clear understanding, we are sticking with: > If the route search fails, > the sender assumes the destination is unreachable. > I haven't seen comments from any other implementors. It would be very > interesting to hear if you have solved this and how you implemented it. We (KAME) adopted a simple (and perhaps naive approach); using the default interface. However, we disabled the ability to specify the default interface by default due to the exact reason discussed here. For more details, please refer to Section 1.2 of the KAME implementation note, the latest version of which is available at: http://orange.kame.net/dev/cvsweb2.cgi/kame/IMPLEMENTATION?rev=1.329&content-type=text/x-cvsweb-markup The following is the related part of the note. IPv6 on-link determination rule (RFC2461) is quite different from assumptions in BSD IPv4 network code. To implement the behavior in RFC2461 section 6.3.6 (3), the kernel needs to know the default outgoing interface. To configure the default outgoing interface, use commands like "ndp -I de0" as root. Then the kernel will have a "default" route to the interface with the cloning "C" bit being on. This default route will cause to make a neighbor cache entry for every destination that does not match an explicit route entry. Note that we intentionally disables configuring the default interface by default. This is because we found it sometimes caused inconvenient situation while it was rarely useful in practical usage. For example, consider a destination that has both IPv4 and IPv6 addresses but is only reachable via IPv4. Since our getaddrinfo(3) prefers IPv6 by default, an (TCP) application using the library with PF_UNSPEC first tries to connect to the IPv6 address. If we turn on RFC 2461 6.3.6 (3), we have to wait for quite a long period before the first attempt to make a connection fails. If we turn it off, the first attempt will immediately fail with EHOSTUNREACH, and then the application can try the next, reachable address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 17 01:48:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H9m07f008837; Mon, 17 Mar 2003 01:48:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2H9m06G008836; Mon, 17 Mar 2003 01:48:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2H9ls7f008826 for ; Mon, 17 Mar 2003 01:47:54 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2H9m2jO023765 for ; Mon, 17 Mar 2003 01:48:02 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10985 for ; Mon, 17 Mar 2003 01:47:55 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 09:47:00 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 09:46:58 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 09:46:58 Z Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 09:46:57 Z From: Masataka Ohta Message-Id: <200303170941.SAA20345@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA20345; Mon, 17 Mar 2003 18:41:10 +0900 Subject: Re: dns discovery for agenda? [Re: chairs and charter] In-Reply-To: <20030317060620.GA24236@login.ecs.soton.ac.uk> from Tim Chown at "Mar 17, 2003 06:06:20 am" To: Tim Chown Date: Mon, 17 Mar 2003 18:41:09 +0859 () CC: Johan Ihren , Pekka Savola , dns op wg , ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim; > I think that, > for example, advertising DNS by RA's in IPv6 offers a veru useful "missing > piece" in the stateless autoconfiguration puzzle. No, not at all. > I have no objection to it > as *a* method, but in the scenario of my home network I'd be quite happy > to run without statelessly configuring clients needing to use DHCP to get > the DNS info. The issue is merely that "stateless" approach is hopeless only to cause a lot of problems when its application is seriously considered. It is a problem of IPng group to remove "stateless" approach from IPv6 specification. Masataka Ohta -------------------------------------------------------------------- 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 Mar 17 05:25:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HDPI7f009661; Mon, 17 Mar 2003 05:25:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2HDPI21009660; Mon, 17 Mar 2003 05:25:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HDPE7f009653 for ; Mon, 17 Mar 2003 05:25:14 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2HDP9P08026; Mon, 17 Mar 2003 14:25:10 +0100 (MET) Date: Mon, 17 Mar 2003 14:21:11 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Alain Durand Cc: Erik Nordmark , Sebastien Roy , "Bound, Jim" , Ronald van der Pol , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What is the benefit of doing so versus doing the change in ndpd? NDP working as designed in RFC 2461. > In that case, it make sense to maintain the local subnet route > but remove the default route. Destination on the local subnet will > still be reachable, other further destination won't and we will not > try them. This can be done in ndpd. In another message I think I pointed out that we want NDP to work when there are no prefixes advertised with the O-bit set (even though the prefixes are on-link). For instance, this might be part of a potential solution to better deal with hidden terminal problems in wireless networks. 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 Mar 17 08:21:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HGLC7f010755; Mon, 17 Mar 2003 08:21:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2HGLB9x010754; Mon, 17 Mar 2003 08:21:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HGL77f010744 for ; Mon, 17 Mar 2003 08:21:07 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2HGLFjO002819 for ; Mon, 17 Mar 2003 08:21:15 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22128 for ; Mon, 17 Mar 2003 08:21:09 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 16:21:08 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 16:21:07 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 16:21:06 Z Received: from starfruit.itojun.org ([130.129.142.194] [130.129.142.194]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 16:21:04 Z Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 41542791; Tue, 18 Mar 2003 01:20:22 +0900 (JST) To: Erik Nordmark Cc: ettikan.kandasamy.karuppiah@intel.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, mrw@windriver.com In-reply-to: Erik.Nordmark's message of Sun, 16 Mar 2003 19:06:47 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt From: Jun-ichiro itojun Hagino Date: Tue, 18 Mar 2003 01:20:22 +0900 Message-Id: <20030317162022.41542791@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> i guess title of section 3 was vague - "current proposals" tries to mean >> "current proposals made for IPv6", like RFC2373 limitation for IPv6 >> anycast address assignment. therefore, 3.3 talks about restriction >> imposed by RFC2373, which is applicable to IPv6 only. >> i'll update title of section 3 to be more clear, and make sure to >> remove any IPv4 topic from section 3. >But RFC 2373 is more than a proposal - it is the IPv6 addressing architecture. >Even if some folks might want to change it I think it can be confusing to >calling it a proposal - the "current state of IPv6 anycast architecture" >might be more accurate since it indicates potential future changes without >treating it as merely a proposal. ok, will think about the section title. >> the paragraph tries to say: >> - if we use predefined site-local anycast address, the propagation of >> host route (/128) would be limited within the site, therefore it may >> be permissible (depending on the routing table size of the site) >or they might even be aggregated at an IGP area boundary... > >> - if we use predefined global anycast address, host route needs to be >> carried worldwide and we will see problems like you mentioned above. >> >> how should i word it for clarity? >Point out in section 1 that anycast addresses have route scalaing issues. >If anycast addresses are drawn from the unicast address space (as is the case >in IPv6 and the IPv4 DNS anycast) the routing scaling impact can potentially >be limited by aggregating the anycast addresses as part of the regular unicast >routing prefixes. But this aggregation can only be applied when all members in >the anycast group remaing within the piece of toplogy whose routes get >aggregated. >For instance having an anycast address where all the members belong to >one ISP means it the anycast address can be drawn from the ISPs address space >and be aggregated at the ISP boundary with no effect on route scaling outside >that domain. But having e.g. anycast groups with members across the whole >Internet will have effect on the size of the routing tables globally. > >Does that capture what you want to say? yes. >> quoting RFC2181: >> >> will be able to use it for further queries. Servers configured in >> >> such a way that not all their addresses are equally reachable from >> >> all potential clients need take particular care when responding to <--- >> >> queries sent to anycast, multicast, or similar, addresses. <--- >> from the above text, it is clear that client should/can not check the >> source address of the reply in the above case. >Your notion of clarity seems quite different than mine. >Section 4 in 2181 is about server behavior with recommendations on how to >make servers work with a large range of different client behavior. >But that doesn't mean that you can infer recommended or required client >behavior from that section. then how can we make servers and clients interact? >> routers will know that the host is authorized to inject a route to >> the routing system, by the fact that it knows the shared secret >> used by the routing protocol (if the route is advertised with proper >> authentication encapsulation/extension header, it is authorized). >> do i need to be more clear on such trivial thing? if so, how? >But if the host knows the shared secret used by the routing protocol it >can inject any route (e.g. default or some other prefix). >For anycast presumably one would want to restrict the host to only >inject a particular host route. i don't think so. you can say the same thing about routers - one would want certain router to be able to inject certain routes only, not the default route/whatever. there's no such protocol available today. (s-bgp?) itojun -------------------------------------------------------------------- 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 Mar 17 09:19:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HHJC7f011542; Mon, 17 Mar 2003 09:19:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2HHJCUJ011541; Mon, 17 Mar 2003 09:19:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HHJ87f011534 for ; Mon, 17 Mar 2003 09:19:08 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2HHJGcU005355 for ; Mon, 17 Mar 2003 09:19:16 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10579 for ; Mon, 17 Mar 2003 09:19:09 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 17:19:09 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 17:16:38 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 17:19:08 Z Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 17:19:06 Z Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2HHHFgU028709; Mon, 17 Mar 2003 12:17:19 -0500 (EST) Received: from nc.rr.com ([130.129.130.143]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 17 Mar 2003 12:16:43 -0500 Message-Id: <3E7602FE.9070505@nc.rr.com> Date: Mon, 17 Mar 2003 12:16:46 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EricLKlein CC: v6ops@ops.ietf.org, eos@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Question about IPv6 Management References: <7D5D48D2CAA3D84C813F5B154F43B155012719C2@nl0006exch001u.nl.lucent.com> <002201c2ec52$3f61e990$67061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, Take a look at the following: draft-ietf-ipv6-rfc2096-update-02.txt draft-ietf-ipv6-rfc2013-update-00.txt draft-ietf-ipv6-rfc2012-update-02.txt draft-ietf-ipv6-rfc2011-update-02.txt Regards, Brian EricLKlein wrote: > Thank you. I have been reading: > RFC 2452 IP v6 MIB for the TCP > > RFC 2454 IP v6 MIB for the UDP > > RFC 2466 MIB for IP v6 ICMP > > But didn't see anything more detailed. Thanks for the information. > Eric > ----- Original Message ----- > From: Wijnen, Bert (Bert) > To: EricLKlein ; v6ops@ops.ietf.org ; eos@ops.ietf.org ; ipng@sunroof.eng.sun.com > Sent: Monday, March 17, 2003 2:48 AM > Subject: RE: Question about IPv6 Management > > > We have been defining a number of things so that IP (or better Internet) addresses > can be represented in an IPversion neutral matter. See for example RFC3291. > > We are checking all MIB modules to be IPv4 and IPv6 capable (unless a module > is for one specific IP version). > > We have defined TCs so that we also have IPv6 transport addresses so that > SNMP can go over IPv6. See RFC3419 > > Various MIB modules are being reqorked in the IPv6 WG > > Hope this helps > Thanks,Bert > > -----Original Message----- > From: EricLKlein [mailto:ericlklein@softhome.net] > Sent: zondag 16 maart 2003 11:19 > To: v6ops@ops.ietf.org; eos@ops.ietf.org; ipng@sunroof.eng.sun.com > Subject: Question about IPv6 Management > > > I appologize, this is being possted to multiple WG's as it seems to cross areas. > > Is there any information about the requirment changes in the Network Management Systems (NMS) or Operations Support Systems (OSS) necesary to support IPv6? > > I have looked at the various MIB RFC's and such, but can not find anything more than you need bigger address support and some SNMPv2 compliance. > > This seems too simple to me. > > Eric > -------------------------------------------------------------------- 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 Mar 17 11:08:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HJ8k7f012254; Mon, 17 Mar 2003 11:08:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2HJ8jZu012253; Mon, 17 Mar 2003 11:08:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HJ8e7f012239 for ; Mon, 17 Mar 2003 11:08:41 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2HJ8iP13476; Mon, 17 Mar 2003 20:08:44 +0100 (MET) Date: Mon, 17 Mar 2003 19:38:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dual stack & IPv6 on by default To: Tim Chown Cc: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20030317064804.GG24236@login.ecs.soton.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > A possible way to approach this problem would be to make > > the choice between A and AAAA be a function of whether there > > is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). > > Note this cuts both ways. I've been in dual-protocol networks where IPv4 > has been down and IPv6 up, so we ought to consider the general case of > availability of connectivity off-link for either protocol. Good point and I agree in principle. But the rules for detecting the lack of connectivity are likely to be different in the IPv6 and IPv4 cases. In IPv6 either RAs or some routing protocol provides routes to the node. Thus the existence of (non manually configured) off-link routes indicate the at least the first hop IPv6 routing is working. In IPv4 in addition to dynamic schemes, the DHCP server can hand out a default route. But that router itself might not be working. Thus would it make sense to be more "suspecious" about IPv4 default routes than in the IPv6 case somehow? 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 Mar 17 11:08:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HJ8o7f012257; Mon, 17 Mar 2003 11:08:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2HJ8onH012256; Mon, 17 Mar 2003 11:08:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HJ8g7f012243 for ; Mon, 17 Mar 2003 11:08:43 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2HJ8lP13492; Mon, 17 Mar 2003 20:08:47 +0100 (MET) Date: Mon, 17 Mar 2003 19:58:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: chakrabarti-ipv6-addrselect-api-00 comments To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ==> perhaps validation functions would be nice, but generally speaking, it > is not possible to, for certainty, to ensure what an address is or isn't? In some cases yes, but there are some issues related e.g. to the late binding of source addresses for e.g. UDP. For instance, if you specify PREFER_SRC_TMP with the semantics of it being a requirement (i.e. REQUIRE_SRC_TMP) then getaddrinfo() might succeed, the setsockopt might succeed, yet when you go to send a UDP packet then sendto() would have to fail because there is no more a temporary source address available for the destination to which you are trying to send. When using TCP then the failure would appear at the time of connect which is better, but it might still be hard to react reasonably to such failures. The validation allows doing a getsockname() after connect() to see what address the socket ended up with, which allows for "softer" error handling. Thus I don't think we can do only hard requirements but that we also need to be able to express preferences. And preferences + validation seems to be able to solve what you can do with preferences + requirements. > ==> Please clarify whether you meant a macro like "IN6_IS_ADDR_LOOPBACK" or > something "verify whether this address assigned on the node was of type > X"? Given that there is an extensible set of flags it might make more sense to define the validation as a function which take the flags as arguments e.g. inet6_is_addr(struct in6_addr *, uint32_t flags) where the flags contain the SRC_PREFER flag set. 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 Mar 17 11:24:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HJOY7f012501; Mon, 17 Mar 2003 11:24:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2HJOYOh012500; Mon, 17 Mar 2003 11:24:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HJOV7f012493 for ; Mon, 17 Mar 2003 11:24:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2HJOdcU022335 for ; Mon, 17 Mar 2003 11:24:39 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04640 for ; Mon, 17 Mar 2003 12:24:33 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 17 Mar 2003 19:24:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Mon, 17 Mar 2003 19:22:00 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Mon, 17 Mar 2003 19:24:31 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP; Mon, 17 Mar 2003 19:24:30 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2HJOQp02591; Mon, 17 Mar 2003 21:24:26 +0200 Date: Mon, 17 Mar 2003 21:24:26 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: chakrabarti-ipv6-addrselect-api-00 comments In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 17 Mar 2003, Erik Nordmark wrote: > Thus I don't think we can do only hard requirements but that we also need > to be able to express preferences. And preferences + validation seems to be > able to solve what you can do with preferences + requirements. > > > ==> Please clarify whether you meant a macro like "IN6_IS_ADDR_LOOPBACK" or > > something "verify whether this address assigned on the node was of type > > X"? > > Given that there is an extensible set of flags it might make more sense to > define the validation as a function which take the flags as arguments > e.g. > inet6_is_addr(struct in6_addr *, uint32_t flags) > where the flags contain the SRC_PREFER flag set. That didn't answer the question, but I assume you meant that the v6 address being validated must belong to the node performing validation? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 17 13:11:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HLB37f013293; Mon, 17 Mar 2003 13:11:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2HLB39D013292; Mon, 17 Mar 2003 13:11:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2HLAw7f013285 for ; Mon, 17 Mar 2003 13:10:59 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2HLAxP22162; Mon, 17 Mar 2003 22:11:00 +0100 (MET) Date: Mon, 17 Mar 2003 22:07:01 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: chakrabarti-ipv6-addrselect-api-00 comments To: Pekka Savola Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That didn't answer the question, but I assume you meant that the v6 > address being validated must belong to the node performing validation? Sorry for my poor reading. In general it makes sense to restrict the address verification to run on the node itself. While some aspects (such as temporary vs. public) can be determined on other nodes, telling the difference between a home address and a care of address can only be done on the node itself. 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 Mar 17 16:49:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I0nP7f015681; Mon, 17 Mar 2003 16:49:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I0nPrl015680; Mon, 17 Mar 2003 16:49:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I0nL7f015671 for ; Mon, 17 Mar 2003 16:49:22 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2I0nOP07084; Tue, 18 Mar 2003 01:49:24 +0100 (MET) Date: Tue, 18 Mar 2003 01:45:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on sl-impact-02 To: Margaret Wasserman Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5.1.0.14.2.20030315072216.0404dd00@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone have an implementation today that has any special > handling for multi-interface links? If you want to send a > packet to a LL address, are you supposed to send it out all of > the interfaces for that link, or only one of them (if so, which > one)? The way multi-interfaces to a link work in Solairs (using something called IP Multipathing) is merely a re-interpretation of API constructs. For instance, if an application says it wants to send multicast packets out a particular interface (using IPV6_MULTICAST_IF) the stack reinterprets this as "any interface in the group of interfaces attached to the same link". The reason for this reinterpretation is because the purpose of this multipathing feature is resiliency against interface failures. If the API was different (e.g. IPV6_MULTICAST_IF was instead called IPV6_MULTICAST_ZONE with a scope zone id) the reinterpretation wouldn't be necessary I think. But the packet only goes out one interface in any case. 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 Mar 17 16:55:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I0tt7f015805; Mon, 17 Mar 2003 16:55:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I0tsh0015804; Mon, 17 Mar 2003 16:55:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I0tp7f015797 for ; Mon, 17 Mar 2003 16:55:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2I0txjO001713 for ; Mon, 17 Mar 2003 16:55:59 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29022 for ; Mon, 17 Mar 2003 17:55:54 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 00:55:53 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 00:55:53 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 00:55:53 Z Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 00:55:52 Z Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2I0ton00231 for ; Mon, 17 Mar 2003 19:55:50 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Mar 2003 19:55:51 -0500 Message-Id: <3549C09B853DD5119B540002A52CDD34069F899B@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: ipng@sunroof.eng.sun.com Subject: UDP MIB Comments Date: Mon, 17 Mar 2003 19:55:50 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi I did a quick search of the archive and didn't see these brought up. Here are some comments about the updated UDP MIB: 1. It seems the data type of the udpLocalPort object has been accidentally changed from INTEGER to Integer32. I know it is being deprecated, but it would be good to correct that anyways. 2. Have we given thought to removing the 32bit counters? SNMPv1 is officially historic, so the only other concern is resources. 3. Why isn't there an udpEndPointRemoteAddressType object? Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada -------------------------------------------------------------------- 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 Mar 17 18:46:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I2kp7f016864; Mon, 17 Mar 2003 18:46:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I2kpHA016863; Mon, 17 Mar 2003 18:46:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I2kl7f016856 for ; Mon, 17 Mar 2003 18:46:47 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2I2kscU029071 for ; Mon, 17 Mar 2003 18:46:55 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06970 for ; Mon, 17 Mar 2003 18:46:49 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 02:46:48 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 02:46:47 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 02:46:47 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 02:46:47 Z Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id CAA14414; Tue, 18 Mar 2003 02:46:29 GMT Received: from pandora.ecs.soton.ac.uk (pandora.ecs.soton.ac.uk [152.78.68.157]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h2I2kOgq004741; Tue, 18 Mar 2003 02:46:24 GMT Received: (from tjc@localhost) by pandora.ecs.soton.ac.uk (8.11.6+Sun/8.11.6) id h2I2kOI14968; Tue, 18 Mar 2003 02:46:24 GMT Date: Tue, 18 Mar 2003 02:46:24 +0000 From: Tim Chown To: Masataka Ohta Cc: Johan Ihren , Pekka Savola , dns op wg , ipng@sunroof.eng.sun.com Subject: Re: dns discovery for agenda? [Re: chairs and charter] Message-Id: <20030318024623.GL8313@pandora.ecs.soton.ac.uk> Mail-Followup-To: Masataka Ohta , Johan Ihren , Pekka Savola , dns op wg , ipng@sunroof.eng.sun.com References: <20030317060620.GA24236@login.ecs.soton.ac.uk> <200303170941.SAA20345@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200303170941.SAA20345@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.3.25i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 17, 2003 at 06:41:09PM +0859, Masataka Ohta wrote: > > It is a problem of IPng group to remove "stateless" approach from IPv6 > specification. Oh, nothing radical then... -------------------------------------------------------------------- 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 Mar 17 19:56:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I3uv7f017380; Mon, 17 Mar 2003 19:56:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I3uvGK017379; Mon, 17 Mar 2003 19:56:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I3us7f017372 for ; Mon, 17 Mar 2003 19:56:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2I3v2cU015033 for ; Mon, 17 Mar 2003 19:57:02 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12417 for ; Mon, 17 Mar 2003 20:56:56 -0700 (MST) From: matthew.ford@bt.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 03:56:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 03:54:24 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 03:56:56 Z Received: from cbibipnt02.HC.BT.COM ([193.113.57.20] [193.113.57.20]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 03:56:55 Z Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 18 Mar 2003 03:57:03 -0000 Message-Id: To: ipng@sunroof.eng.sun.com Subject: slides Date: Tue, 18 Mar 2003 03:56:48 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk will the slides from today's meeting be made available somewhere? mat. -------------------------------------------------------------------- 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 Mar 17 20:38:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I4cT7f017681; Mon, 17 Mar 2003 20:38:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I4cTRM017680; Mon, 17 Mar 2003 20:38:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I4cP7f017673 for ; Mon, 17 Mar 2003 20:38:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2I4cXcU022584 for ; Mon, 17 Mar 2003 20:38:33 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07183 for ; Mon, 17 Mar 2003 20:38:28 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:37:53 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:35:20 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:37:53 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:37:52 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA15522; Mon, 17 Mar 2003 20:37:50 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2I4bn910158; Mon, 17 Mar 2003 20:37:49 -0800 X-mProtect: <200303180437> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.48.152, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnrHkcQ; Mon, 17 Mar 2003 20:37:47 PST Message-Id: <3E76A29A.6020708@iprg.nokia.com> Date: Mon, 17 Mar 2003 20:37:46 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: Sebastien Roy , "Bound, Jim" , Ronald van der Pol , Alain Durand , v6ops@ops.ietf.org, jim.Paugh@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm just dropping into this thread, and maybe this idea has already come up. But, when the DNS returns both A and AAAA records for a destination and when there is no v6 route, why can't the source just do automatic v6-in-v4 tunneling using an address from an AAAA record as the v6dst and an address from an A record as the v4dst? Gives you a decision tree of sorts, i.e.: 1) when an AAAA record and a v6 route exist, use native v6. Else: 2) when both AAAA and A records exist, but no v6 route, use automatic v6-in-v4 tunneling. Else: 3) when an A record exists, use v4. Else: 4) destination unreachable Fred ftemplin@iprg.nokia.com Erik Nordmark wrote: >>That's a really good question. I'm not sure what would be the best way >>to address this. What we're saying in this draft is that operational >>experience has shown that this part of ND could be problematic in some >>circumstances. Does ND need to be changed as a result? Probably not. >>There are no MUST's surrounding that bit of ND. As implementors, we're >>free to interpret the spec in a sane mannor. With this draft, we're >>pointing out reasons why implementors may want to be careful with that >>part of ND. There is informational value in this alone without having >>to muck with the ND spec itself. >> >> > >A possible way to approach this problem would be to make >the choice between A and AAAA be a function of whether there >is one or more IPv6 route off-link (or at least one IPv6 router sending RAs). > >That way you don't have to tweak ND. But you do end up with some >having e.g. getaddrinfo() check with the kernel. I think getaddrinfo() >needs to already do some checks in order to implement the default address >selection document. > > > >>If you don't have a route to the destination, why try to reach it >>on-link just in case the destination might happen to be on-link? Is >>there a situation where this would be useful? >> >> > >If you have two nodes communicating on a link and the router >dies for long enough time it seems useful to be able to >continue to communicate. Of course, the communication will fail >once the addresses become invalid but that might take a long time. > > 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 Mon Mar 17 20:47:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I4lO7f017968; Mon, 17 Mar 2003 20:47:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I4lOq0017965; Mon, 17 Mar 2003 20:47:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I4lL7f017958 for ; Mon, 17 Mar 2003 20:47:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2I4lTcU024018 for ; Mon, 17 Mar 2003 20:47:29 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03019 for ; Mon, 17 Mar 2003 20:47:23 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:47:23 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:47:22 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:47:22 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 04:47:22 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2I4lKSo013098 for ; Tue, 18 Mar 2003 05:47:20 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2I4lJL9056450 for ; Tue, 18 Mar 2003 05:47:20 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25344 from ; Tue, 18 Mar 2003 05:47:17 +0100 Message-Id: <3E76A496.67363BF2@hursley.ibm.com> Date: Tue, 18 Mar 2003 05:46:14 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: [Fwd: Issue #1 [Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)]] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Contrary to what I said in the meeting 5 minutes ago, I did look at this issue, and agreed with cmh's recommendation. Nobody on the diffserv list responded. Brian -------- Original Message -------- Subject: Issue #1 [Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2)] Date: Fri, 31 Jan 2003 14:37:26 +0100 From: Brian E Carpenter Organization: IBM To: "C. M. Heard" CC: ipng@sunroof.eng.sun.com References: "C. M. Heard" wrote: ... > Synopsis: I question the appropriateness of using the DSCP field > to represent routing policy, and I recommend replacing the > inetCidrRouteDscp object with a more generic inetCidrRoutePolicy > object. Personally, I agree. This possible usage of the DSCP is too speculative to bless it in a MIB. Writing as diffserv co-chair, your blind copy to the diffserv list was filtered as possible spam, but I have released from limbo so we should see if there is any reaction from that community. Brian -------------------------------------------------------------------- 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 Mar 17 21:38:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I5cP7f018790; Mon, 17 Mar 2003 21:38:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I5cO7K018789; Mon, 17 Mar 2003 21:38:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I5cL7f018776 for ; Mon, 17 Mar 2003 21:38:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2I5cTcU003737 for ; Mon, 17 Mar 2003 21:38:29 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07010 for ; Mon, 17 Mar 2003 22:38:23 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:38:23 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:35:50 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:38:22 Z Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:38:22 Z Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2I5cKKn027830 for ; Mon, 17 Mar 2003 21:38:20 -0800 (PST) Received: from SIVAV.qualcomm.com (vpn-10-50-16-24.qualcomm.com [10.50.16.24]) by neophyte.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2I5cIxr023073 for ; Mon, 17 Mar 2003 21:38:18 -0800 (PST) Message-Id: <4.3.2.7.2.20030317200020.02ff81b8@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Mar 2003 21:38:01 -0800 To: ipng@sunroof.eng.sun.com From: Siva Veerepalli Subject: Updates to PPPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The current work items in the wg charter and Margaret's presentation on document status in the WG meeting shows PPPv6 as one of the items. Could someone clarify what the changes/updates being considered for IPv6 over PPP rfc are? Are they technical or editorial/clarification of existing text? Thanks, Siva -------------------------------------------------------------------- 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 Mar 17 21:38:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I5cd7f018806; Mon, 17 Mar 2003 21:38:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2I5cdkO018805; Mon, 17 Mar 2003 21:38:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2I5cW7f018795 for ; Mon, 17 Mar 2003 21:38:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2I5cejO009186 for ; Mon, 17 Mar 2003 21:38:40 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA10146 for ; Mon, 17 Mar 2003 22:38:32 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:38:26 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:38:26 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:38:25 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 05:38:25 Z Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id FAA15105; Tue, 18 Mar 2003 05:38:23 GMT Received: from pandora.ecs.soton.ac.uk (pandora.ecs.soton.ac.uk [152.78.68.157]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id h2I5cGgq025424; Tue, 18 Mar 2003 05:38:16 GMT Received: (from tjc@localhost) by pandora.ecs.soton.ac.uk (8.11.6+Sun/8.11.6) id h2I5cGP15618; Tue, 18 Mar 2003 05:38:16 GMT Date: Tue, 18 Mar 2003 05:38:16 +0000 From: Tim Chown To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: dual stack & IPv6 on by default Message-Id: <20030318053812.GF15110@pandora.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, ipng@sunroof.eng.sun.com References: <3E76A29A.6020708@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E76A29A.6020708@iprg.nokia.com> User-Agent: Mutt/1.3.25i X-ECS-MailScanner: Found to be clean Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 17, 2003 at 08:37:46PM -0800, Fred L. Templin wrote: > I'm just dropping into this thread, and maybe this idea has already come up. > But, when the DNS returns both A and AAAA records for a destination and > when there is no v6 route, why can't the source just do automatic v6-in-v4 > tunneling using an address from an AAAA record as the v6dst and an address > from an A record as the v4dst? Gives you a decision tree of sorts, i.e.: In principle reasonable, but many things may still cause failure, e.g. - the tunnelling fails due to firewall blocks - the IPv4 connectivity is down - the A and AAAA records may point to different hosts 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 Tue Mar 18 07:06:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IF6e7f021744; Tue, 18 Mar 2003 07:06:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IF6eRc021743; Tue, 18 Mar 2003 07:06:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IF6b7f021736 for ; Tue, 18 Mar 2003 07:06:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IF6icU024543 for ; Tue, 18 Mar 2003 07:06:45 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12462 for ; Tue, 18 Mar 2003 07:06:38 -0800 (PST) From: jarno.rajahalme@nokia.com Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 14:52:12 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 14:05:18 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 14:05:18 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 14:05:17 Z Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2IE3qM14578 for ; Tue, 18 Mar 2003 16:03:52 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Mar 2003 16:05:15 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Mar 2003 16:05:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Date: Tue, 18 Mar 2003 16:05:14 +0200 Message-Id: <009CA59D1752DD448E07F8EB2F9117570216EB5C@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Thread-Index: AcLikT5Nvg7ebK4yTuy+Qp9HUeTzbwKuQfOg To: , , , Cc: X-OriginalArrivalTime: 18 Mar 2003 14:05:14.0955 (UTC) FILETIME=[660841B0:01C2ED57] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2IF6b7f021737 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, March 04, 2003, Pekka Savola wrote: > On Tue, 4 Mar 2003, Bob Hinden & Margaret Wasserman wrote: > > This is a one week IPv6 working group last call for > comments on advancing > > the following document as a Proposed Standard: > > > > Title : IPv6 Flow Label Specification > > Author(s) : J. Rajahalme, A. Conta, B. Carpenter, > S. Deering > > Filename : draft-ietf-ipv6-flow-label-05.txt > > Pages : 8 > > Date : 2003-3-3 > > ... > substantial: > ------------ > > The 3-tuple of the Flow Label and the Source and > Destination Address > fields enables efficient IPv6 flow classification, where only IPv6 > main header fields in fixed positions are used. > > ==> this might require some extra analysis somewhere (not in that > particular place, I think). In particular, this seems to say > that once > this is published people can happily move to using the three-tuple > classification. The reality is probably quite different, and > one must > also consider the big portion of nodes which do not mark the flows. > Maybe the text is too lean. The meaning should be that this spec enables the flows to be labeled, and when labeled, efficient classification is possible. It is also said in the beginning of section 4 that the classification is meaningless, unless the nodes somehow communicate the "semantics" of the flows to the nodes performing the classification. This is the role of the flow state establishment methods, which are to be defined separately. > A possible fix would be to tone down "enable" (e.g. "make xxx > possible") > and add some minor tweaking. > Maybe the following edit would make this point clear: "The usage of the 3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used." Comments? > To enable applications and transport protocols to define > what packets > constitute a flow, the source node MUST provide means for the > applications and transport protocols to specify the Flow > Label values > to be used with their flows. > > ==> this requirement seems unacceptable at the moment. This clearly > requires (at least) de-facto API so applications could set Flow Label > values -- and as such does not exist. If it did (and I > believe there's > work in progress), there would *have to be* a normative > reference to it). > So, clearly a MUST seems to a big no-no. > I agree that a standard or de-facto API would be highly desirable for application writers, but I have had the impression that specifying APIs is not the concern of the IETF. So even if the standard existed the reference to it should be informative (even if the functionality is a MUST). If somebody's business model calls for proprietary APIs, we (as IETF) should not care. My personal view is that the MUST is needed to get the API definitions /standardization to happen. If it was a SHOULD, an stack implementer might think *he* has a valid reason not implementing the interface, rendering the flow labeling useless for uses that require the applications to be in control of the value for a particular flow. Also, placing the requirement weaker than MUST, and waiting for API specifications, and then revving the standard with a MUST would be bad practice, IMO. Also, I don't think that it is too bad if initial implementations have proprietary interfaces, as even it would be an improvement over the existing situation. In an earlier revision of the document we had text about an abstract interface definition, but it was removed from the doc under WG consensus. > A source node MUST ensure that it does not reuse Flow > Label values it > is currently using or has recently used when creating new > flows. Flow > Label values previously used with a specific pair of source and > destination addresses MUST NOT be assigned to new flows > with the same > address pair within 120 seconds of the termination of the previous > flow. > > ==> so, if I make create a raw socket, manually fiddle in the > flow label > value which was previously used, and send the packet, the > operating system > kernel should hijack it and prevent it from going out? Get > real. Perhaps > s/reuse/unintentionally reuse/, or some other rewording? > "unintentionally" is exactly what it means, so there is no problem doing this edit. This is related the API-issue above, as the interface is required for the applications to be able to specify which packets belong to which flow. No raw socket is needed for the fiddling, as the interface enabling this is a MUST requirement already! The operating system of the kernel should definitely not hijack anything, but honor the value the application sets through the implemented API. This also touches on the "trust on the end node" issue you refer below. More on this below. > To enable co-existence of different methods in IPv6 nodes, the > methods MUST meet the following basic requirements: > > ==> this and the following points seem a little oddly placed > in this memo: > they seem out-of-place, as the rest of the memo seems to > concentrate on > entirely different issues. Personally I view specifying how > source nodes > should label flows one thing, and the rest entirely another. > But I can > live with these, even though I think they're more fit to a > non-standards > track document. > The title of the section is "Flow State Establishment Requirements", which clearly sets it apart from the previous section ("Flow Labeling Requirements"). The editorial problem here is that labeling requirements already enable most of what is needed for the flow state establishment methods, and there is only a little to add in the section 4. The most important part of the section 4 is the first paragraph: "To enable flow-specific treatment, flow state needs to be established on all or a subset of the IPv6 nodes on the path from the source to the destination(s). The methods for the state establishment, as well as the models for flow-specific treatment will be defined in separate specifications." It should be noted that without such a separate specifications for specifying how nodes inform each other about the flows they have defined, the flow label is going to find only little use, as the labeling as seen by a node in the path typically makes no sense: there is nothing a router could do based on classifying the flows without being told what to do to the packets, once classified (perhaps keeping the packet of a flow on the same next-hop is an exception here). IMO the trust issues should be handled on the flow state establishment method -level: Why would a node believe that a request for a flow -specific handling should be honored? > 5.1 Theft and Denial of Service > > ==> this section mainly deals with issues relating to forging > all of the > source,destination,label three-tuple (exception is the last > paragraph, > which deals with a trusted-node-but-untrusted-user/application case), > which protects mainly against a DoS attack (resource depletion). > > This seems to overlook the most important part: the typical > model today is > that operators perform differentiation of flows *themselves*: this > document proposes to shift that, *over an administrative > boundary*, to the > source nodes, which suddenly become trusted to do the right thing. > I would rather state that the nodes do what they want, and the operators do what they want based on that. In the positive case someone comes up with a specification allowing flow set-up over the administrative interface. In the meanwhile the operators continue classifying as they see fit based on whatever fields they were using before. > This would be equivalent to replacing network ingress > filtering (to drop > packets with forged source addresses) to a requirement for > nodes to allow > out only packets which include their own source address. > > Needless to say this seems to indicate a major oversight of the > security/operational reality. I'd be very surprised if this was not > pushed back in the IESG unless this caveat is very explicitly > documented. > There is no operational implication expected due to this specification. It would be the flow state establishment methods and their application that would result in new operational reality. Maybe this should be clearly stated in the text? > semi-editorial > -------------- > > Nodes keeping dynamic flow state MUST NOT assume packets > arriving 120 > seconds or more after the previous packet of a flow still belong to > the same flow, unless a flow state establishment method in use > defines a longer flow state lifetime or the flow state has been > explicitly refreshed within the lifetime duration. > > ==> this is a way too sentence, 5 lines, and constructed in with a > negative: "MUST NOT blahblah, unless foofoo". You really > have to read > that a couple of times to understand what it's trying to say. I'd > strongly urge to reword and simplify. > One alternative way of putting this would be: "Nodes keeping dynamic flow state may assume that packets arriving less than 120 seconds after the previous packet of a flow still belong to the same flow. The time of an explicit flow state refresh by a flow state establishment method is also to be considered as a packet arrival. A longer flow state lifetime may be specified by a flow state establishment method." IMO this has exactly the same (intended) meaning. Would this be better? With regards, Jarno -------------------------------------------------------------------- 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 Mar 18 08:03:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IG3g7f022280; Tue, 18 Mar 2003 08:03:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IG3g8X022279; Tue, 18 Mar 2003 08:03:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IG3d7f022272 for ; Tue, 18 Mar 2003 08:03:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IG3ljO006088 for ; Tue, 18 Mar 2003 08:03:47 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03990 for ; Tue, 18 Mar 2003 09:03:33 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 16:03:06 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 16:00:29 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 16:03:03 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 16:03:00 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2IG2Z711650; Tue, 18 Mar 2003 18:02:35 +0200 Date: Tue, 18 Mar 2003 18:02:34 +0200 (EET) From: Pekka Savola To: jarno.rajahalme@nokia.com cc: brian@hursley.ibm.com, , , Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" In-Reply-To: <009CA59D1752DD448E07F8EB2F9117570216EB5C@esebe004.ntc.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 18 Mar 2003 jarno.rajahalme@nokia.com wrote: > > ==> this might require some extra analysis somewhere (not in that > > particular place, I think). In particular, this seems to say > > that once > > this is published people can happily move to using the three-tuple > > classification. The reality is probably quite different, and > > one must > > also consider the big portion of nodes which do not mark the flows. > > > > Maybe the text is too lean. The meaning should be that this spec enables > the flows to be labeled, and when labeled, efficient classification is > possible. It is also said in the beginning of section 4 that the > classification is meaningless, unless the nodes somehow communicate the > "semantics" of the flows to the nodes performing the classification. This > is the role of the flow state establishment methods, which are to be > defined separately. Ok. > > A possible fix would be to tone down "enable" (e.g. "make xxx > > possible") > > and add some minor tweaking. > > > > Maybe the following edit would make this point clear: > > "The usage of the 3-tuple of the Flow Label and the Source and > Destination Address fields enables efficient IPv6 flow > classification, where only IPv6 main header fields in fixed > positions are used." > > Comments? Fine by me. > > To enable applications and transport protocols to define > > what packets > > constitute a flow, the source node MUST provide means for the > > applications and transport protocols to specify the Flow > > Label values > > to be used with their flows. > > > > ==> this requirement seems unacceptable at the moment. This clearly > > requires (at least) de-facto API so applications could set Flow Label > > values -- and as such does not exist. If it did (and I > > believe there's > > work in progress), there would *have to be* a normative > > reference to it). > > So, clearly a MUST seems to a big no-no. > > > > I agree that a standard or de-facto API would be highly desirable for > application writers, but I have had the impression that specifying APIs > is not the concern of the IETF. So even if the standard existed the > reference to it should be informative (even if the functionality is a > MUST). If somebody's business model calls for proprietary APIs, we (as > IETF) should not care. > > My personal view is that the MUST is needed to get the API definitions > /standardization to happen. If it was a SHOULD, an stack implementer > might think *he* has a valid reason not implementing the interface, > rendering the flow labeling useless for uses that require the > applications to be in control of the value for a particular flow. > > Also, placing the requirement weaker than MUST, and waiting for API > specifications, and then revving the standard with a MUST would be bad > practice, IMO. > > Also, I don't think that it is too bad if initial implementations have > proprietary interfaces, as even it would be an improvement over the > existing situation. > > In an earlier revision of the document we had text about an abstract > interface definition, but it was removed from the doc under WG consensus. This seems to be a similar point to the discussion yesterday at the meeting about deployment problem with RFC3041 addresses, and not being to toggle their use in an application-specific manner (even though the API is must). Personally, I'd rather see whole standards implemented rather than only parts of it. That's why I tend to argue on removing or changing the parts which make implementation or compliance difficult. So, I think a strong SHOULD or a weak MUST is necessary, but I'd like to get feedback particularly from apps folks. > > A source node MUST ensure that it does not reuse Flow > > Label values it > > is currently using or has recently used when creating new > > flows. Flow > > Label values previously used with a specific pair of source and > > destination addresses MUST NOT be assigned to new flows > > with the same > > address pair within 120 seconds of the termination of the previous > > flow. > > > > ==> so, if I make create a raw socket, manually fiddle in the > > flow label > > value which was previously used, and send the packet, the > > operating system > > kernel should hijack it and prevent it from going out? Get > > real. Perhaps > > s/reuse/unintentionally reuse/, or some other rewording? > > > > "unintentionally" is exactly what it means, so there is no problem > doing this edit. This is related the API-issue above, as the > interface is required for the applications to be able to specify > which packets belong to which flow. No raw socket is needed for the > fiddling, as the interface enabling this is a MUST requirement > already! I'm not sure if I agree with your last sentence. If an application requests a specific flow label which is already used by another application at the moment, should the node allow that or return an error? I'd argue for an error, with a possible exception of an app run with "root" privileges. > > To enable co-existence of different methods in IPv6 nodes, the > > methods MUST meet the following basic requirements: > > > > ==> this and the following points seem a little oddly placed > > in this memo: > > they seem out-of-place, as the rest of the memo seems to > > concentrate on > > entirely different issues. Personally I view specifying how > > source nodes > > should label flows one thing, and the rest entirely another. > > But I can > > live with these, even though I think they're more fit to a > > non-standards > > track document. > > > > The title of the section is "Flow State Establishment Requirements", > which clearly sets it apart from the previous section ("Flow Labeling > Requirements"). The editorial problem here is that labeling requirements > already enable most of what is needed for the flow state establishment > methods, and there is only a little to add in the section 4. > > The most important part of the section 4 is the first paragraph: > > "To enable flow-specific treatment, flow state needs to be established > on all or a subset of the IPv6 nodes on the path from the source to > the destination(s). The methods for the state establishment, as well > as the models for flow-specific treatment will be defined in separate > specifications." > > It should be noted that without such a separate specifications for > specifying how nodes inform each other about the flows they have defined, > the flow label is going to find only little use, as the labeling as seen > by a node in the path typically makes no sense: there is nothing a router > could do based on classifying the flows without being told what to do to > the packets, once classified (perhaps keeping the packet of a flow on the > same next-hop is an exception here). Ok. > IMO the trust issues should be handled on the flow state establishment > method -level: Why would a node believe that a request for a flow > -specific handling should be honored? As long as there is a customer relationship (or similar) between the owner of the node and (parts of) the network, this should be a non-issue. > > 5.1 Theft and Denial of Service > > > > ==> this section mainly deals with issues relating to forging > > all of the > > source,destination,label three-tuple (exception is the last > > paragraph, > > which deals with a trusted-node-but-untrusted-user/application case), > > which protects mainly against a DoS attack (resource depletion). > > > > This seems to overlook the most important part: the typical > > model today is > > that operators perform differentiation of flows *themselves*: this > > document proposes to shift that, *over an administrative > > boundary*, to the > > source nodes, which suddenly become trusted to do the right thing. > > > > I would rather state that the nodes do what they want, and the operators > do what they want based on that. In the positive case someone comes up > with a specification allowing flow set-up over the administrative > interface. In the meanwhile the operators continue classifying as they > see fit based on whatever fields they were using before. Well, that might be an approach.. but I'd build on the text I proposed on the list on the separate thread, maybe add something on top of that based on what you say. > > This would be equivalent to replacing network ingress > > filtering (to drop > > packets with forged source addresses) to a requirement for > > nodes to allow > > out only packets which include their own source address. > > > > Needless to say this seems to indicate a major oversight of the > > security/operational reality. I'd be very surprised if this was not > > pushed back in the IESG unless this caveat is very explicitly > > documented. > > There is no operational implication expected due to this specification. It > would be the flow state establishment methods and their application that > would result in new operational reality. Maybe this should be clearly > stated in the text? It's ok to say what's expected, but one should also then say why such thing is expected. In my experience, this w.g. is not the best versed in fleshing out operational implications, and we should assume the worst. > > semi-editorial > > -------------- > > > > Nodes keeping dynamic flow state MUST NOT assume packets > > arriving 120 > > seconds or more after the previous packet of a flow still belong to > > the same flow, unless a flow state establishment method in use > > defines a longer flow state lifetime or the flow state has been > > explicitly refreshed within the lifetime duration. > > > > ==> this is a way too sentence, 5 lines, and constructed in with a > > negative: "MUST NOT blahblah, unless foofoo". You really > > have to read > > that a couple of times to understand what it's trying to say. I'd > > strongly urge to reword and simplify. > > > > One alternative way of putting this would be: > > "Nodes keeping dynamic flow state may assume that packets arriving > less than 120 seconds after the previous packet of a flow still > belong to the same flow. The time of an explicit flow state refresh > by a flow state establishment method is also to be considered as a > packet arrival. A longer flow state lifetime may be specified by a > flow state establishment method." > > IMO this has exactly the same (intended) meaning. Would this be better? This is ok by me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 18 09:32:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IHWi7f022764; Tue, 18 Mar 2003 09:32:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IHWiTK022763; Tue, 18 Mar 2003 09:32:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IHWf7f022756 for ; Tue, 18 Mar 2003 09:32:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IHWncU010029 for ; Tue, 18 Mar 2003 09:32:49 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23902 for ; Tue, 18 Mar 2003 10:32:43 -0700 (MST) From: matthew.ford@bt.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:28:59 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:23:45 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:26:18 Z Received: from cbibipnt08.hc.bt.com ([193.113.57.20] [193.113.57.20]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:26:17 Z Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 18 Mar 2003 17:25:55 -0000 Message-Id: To: ipng@sunroof.eng.sun.com Subject: RESEND: slides Date: Tue, 18 Mar 2003 17:25:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Ford,M,Mat,DEN5 FORDM5 R > Sent: 17 March 2003 19:57 > To: 'ipng@sunroof.eng.sun.com' > Subject: slides > > > will the slides from today's meeting be made available somewhere? > > mat. > -------------------------------------------------------------------- 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 Mar 18 09:50:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IHoj7f023003; Tue, 18 Mar 2003 09:50:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IHojg9023002; Tue, 18 Mar 2003 09:50:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IHog7f022995 for ; Tue, 18 Mar 2003 09:50:42 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IHoocU016731 for ; Tue, 18 Mar 2003 09:50:50 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27719 for ; Tue, 18 Mar 2003 09:50:45 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:50:44 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:50:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:50:42 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 17:50:42 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA10254; Tue, 18 Mar 2003 09:50:41 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2IHof726178; Tue, 18 Mar 2003 09:50:41 -0800 X-mProtect: <200303181750> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (130.129.139.212, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjJyoaL; Tue, 18 Mar 2003 09:50:39 PST Message-Id: <4.3.2.7.2.20030318094620.03253108@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Mar 2003 09:50:16 -0800 To: matthew.ford@bt.com From: Bob Hinden Subject: Re: RESEND: slides Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, they will be available on playground.sun.com/ipv6 and in the meeting proceedings. I will try to get them on playground the week after the meeting. Bob At 09:25 AM 3/18/2003, matthew.ford@bt.com wrote: > > -----Original Message----- > > From: Ford,M,Mat,DEN5 FORDM5 R > > Sent: 17 March 2003 19:57 > > To: 'ipng@sunroof.eng.sun.com' > > Subject: slides > > > > > > will the slides from today's meeting be made available somewhere? > > > > mat. > > -------------------------------------------------------------------- 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 Mar 18 11:22:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IJMT7f023591; Tue, 18 Mar 2003 11:22:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IJMT4Y023590; Tue, 18 Mar 2003 11:22:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IJMP7f023583 for ; Tue, 18 Mar 2003 11:22:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IJMXcU021899 for ; Tue, 18 Mar 2003 11:22:33 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26091 for ; Tue, 18 Mar 2003 12:22:27 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:07:58 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:07:58 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:07:58 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:07:57 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1C04C20D5 for ; Tue, 18 Mar 2003 14:07:57 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Mar 2003 14:07:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Nodes Requirements Input Date: Tue, 18 Mar 2003 14:07:56 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD22@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nodes Requirements Input Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8Pg From: "Bound, Jim" To: X-OriginalArrivalTime: 18 Mar 2003 19:07:57.0078 (UTC) FILETIME=[AF804B60:01C2ED81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2IJMQ7f023584 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk WG, For any show of hands for Thursday a.m. per any discussion of Node Requirements I believe to guage the initial consensus (all meetings must be ratified by follow email and hum is bad show of hands is better) here are some questions that also should be asked. How many people have read and understand RFC 2461? How many people have read and understand RFC 2462? Then the actual question regarding the topic at hand. Below is further input to the Node Requirements document. This document should not be standards track but possibly a BCP? It will change. But I don't believe we need this document except in form suggested further below in this mail. I also believe as I said at WG meeting Monday night I fear we need to determine a set of node requirements documents and a one size fits all will not satisfy all nodes. As Bob Hinden suggested possibly based on "services" as opposed to node types. Also when we did 1122 and 1123 many years ago and then some of us actually implemented those it took us years to get the MAYs done for users and even some SHOULDs. Like it or not implementors are affected by these 2119 terms. Also the specs to day are far better, more robust, more peer review etc. There is less of a need for 1122 and 1123 requirements from the early to mid 80's specifications. We also now have many interoperability tests for IPv6 and it is clear to any vendor that does not pass them and to the market for IPv6 bids. That is the ultimate authority did a vendors node pass the interoperability tests in the public domain. Lastly we need to make sure and listen to who wants what in an addendum to our IPv6 specs and listen to why? More input to the requirements below. > -----Original Message----- > From: Bound, Jim > Sent: Tuesday, March 18, 2003 10:53 AM > To: Bound, Jim > Subject: node reqs prep > > > > 3. Sub-IP Layer > > An IPv6 node must follow the RFC related to the link-layer that is > sending packet. By definition, these specifications are required > based upon what layer-2 is used. In general, it is > reasonable to be > a conformant IPv6 node and NOT support some legacy interfaces. > > As IPv6 is run over new layer 2 technologies, it is > expected that new > specifications will be issued. This section highlights some major > layer 2 technologies and is not intended to be complete. Why are we producing an incomplete document for standards track in IPv6? > > 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 > > Transmission of IPv6 Packets over Ethernet Networks [RFC-2464] MUST > be supported for nodes supporting Ethernet interfaces. > > 3.2 IP version 6 over PPP - RFC2472 > > IPv6 over PPP [RFC-2472] MUST be supported for nodes that use PPP. > > 3.3 IPv6 over ATM Networks - RFC2492 > > IPv6 over ATM Networks [RFC2492] MUST be supported for nodes > supporting ATM interfaces. Additionally, the specification states: > > A minimally conforming IPv6/ATM driver SHALL support > the PVC mode > of operation. An IPv6/ATM driver that supports the full SVC mode > SHALL also support PVC mode of operation. > > 4. IP Layer > > 4.1 Internet Protocol Version 6 - RFC2460 > > The Internet Protocol Version 6 is specified in [RFC-2460]. This > specification MUST be supported. > > Unrecognized options in Hop-by-Hop Options or Destination Options > extensions MUST be processed as described in RFC 2460. > > The node MUST follow the packet transmission rules in RFC 2460. > > Nodes MUST always be able to receive fragment headers. > However, if it > > > > Loughney (editor) March 3, 2003 > [Page 5] > > > > > > Internet-Draft > August 28, 2003 > > > does not implement path MTU discovery it may not need to send > fragment headers. However, nodes that do not implement > transmission > of fragment headers need to impose limitation to payload size of > layer 4 protocols. > > The capability of being a final destination MUST be supported, > whereas the capability of being an intermediate destination MAY be > supported (i.e. - host functionality vs. router functionality). > > RFC 2460 specifies extension headers and the processing for these > headers. > > A full implementation of IPv6 includes implementation of the > following extension headers: Hop-by-Hop Options, > Routing (Type 0), > Fragment, Destination Options, Authentication and Encapsulating > Security Payload. [RFC2460] > > An IPv6 node MUST be able to process these headers. It should be > noted that there is some discussion about the use of > Routing Headers > and possible security threats [IPv6-RH] caused by them. > > 4.2 Neighbor Discovery for IPv6 - RFC2461 > > Neighbor Discovery SHOULD be supported. RFC 2461 states: > > "Unless specified otherwise (in a document that covers operating > IP over a particular link type) this document applies > to all link > types. However, because ND uses link-layer multicast for some of > its services, it is possible that on some link types (e.g., NBMA > links) alternative protocols or mechanisms to implement those > services will be specified (in the appropriate document covering > the operation of IP over a particular link type). The services > described in this document that are not directly dependent on > multicast, such as Redirects, Next-hop determination, Neighbor > Unreachability Detection, etc., are expected to be provided as > specified in this document. The details of how one uses ND on > NBMA links is an area for further study." > > Some detailed analysis of Neighbor discovery follows: > > Router Discovery is how hosts locate routers that reside on an > attached link. Router Discovery MUST be supported for > implementations. However, an implementation MAY support disabling > this function. > > Prefix Discovery is how hosts discover the set of address prefixes > that define which destinations are on-link for an attached link. > Prefix discovery MUST be supported for implementations. > However, the > > > > Loughney (editor) March 3, 2003 > [Page 6] > > > > > > Internet-Draft > August 28, 2003 > > > implementation MAY support the option of disabling this function. > > Neighbor Unreachability Detection (NUD) MUST be supported for all > paths between hosts and neighboring nodes. It is not required for > paths between routers. It is required for multicast. > However, when a > node receives a unicast Neighbor Solicitation (NS) message > (that may > be a NUD's NS), the node MUST respond to it (i.e. send a unicast > Neighbor Advertisement). > > Duplicate Address Detection MUST be supported (RFC2462 section 5.4 > specifies DAD MUST take place on all unicast addresses). > > Sending Router Solicitation MUST be supported for host > implementation, but MAY support a configuration option to disable > this functionality. > > Receiving and processing Router Advertisements MUST be > supported for > host implementation s. However, the implementation MAY support the > option of disabling this function. The ability to > understand specific > Router Advertisements is dependent on supporting the specification > where the RA is specified. > > Sending and Receiving Neighbor Solicitation (NS) and Neighbor > Advertisement (NA) MUST be supported. NS and NA messages > are required > for Duplicate Address Detection (DAD). > > Redirect Function SHOULD be supported. If the node is a router, > Redirect Function MUST be supported. > > 4.3 Path MTU Discovery & Packet Size > > 4.3.1 Path MTU Discovery - RFC1981 > > Path MTU Discovery [RFC-1981] MAY be supported. Nodes with a link > MTU larger than the minimum IPv6 link MTU (1280 octets) > can use Path > MTU Discovery in order to discover the real path MTU. The relative > overhead of IPv6 headers is minimized through the use of longer > packets, thus making better use of the available bandwidth. > > The IPv6 specification [RFC-2460] states in chapter 5 that > "a minimal > IPv6 implementation (e.g., in a boot ROM) may simply > restrict itself > to sending packets no larger than 1280 octets, and omit > implementation of Path MTU Discovery." > > If Path MTU Discovery is not implemented then the sending > packet size > is limited to 1280 octets (standard limit in [RFC-2460]). > However, if > this is done, the host MUST be able to receive packets with size up > to the link MTU before reassembly. This is because the node at the > > > > Loughney (editor) March 3, 2003 > [Page 7] > > > > > > Internet-Draft > August 28, 2003 > > > other side of the link has no way of knowing less than the MTU is > accepted. > > 4.3.2 IPv6 Jumbograms - RFC2675 > > IPv6 Jumbograms [RFC2675] MAY be supported. > > 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 > > ICMPv6 [RFC-2463] MUST be supported. > > 4.5 Addressing > > Currently, there is discussion on-going on support for site-local > addressing. > > 4.5.1 IP Version 6 Addressing Architecture - RFC2373 > > The IPv6 Addressing Architecture [RFC-2373] MUST be supported. > Currently, this specification is being updated by [ADDRARCHv3]. This has changed now. ALso we need to reference Multi6 could affect this end result. > > 4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 > > IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. > This specification MUST be supported for nodes that are hosts. > > Nodes that are routers MUST be able to generate link local > addresses > as described in this specification. > > From 2462: > > The autoconfiguration process specified in this document applies > only to hosts and not routers. Since host autoconfiguration uses > information advertised by routers, routers will need to be > configured by some other means. However, it is expected that > routers will generate link-local addresses using the mechanism > described in this document. In addition, routers are expected to > successfully pass the Duplicate Address Detection procedure > described in this document on all addresses prior to assigning > them to an interface. > > Duplicate Address Detection (DAD) MUST be supported. > > 4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 > > Privacy Extensions for Stateless Address Autoconfiguration > [RFC-3041] > SHOULD be supported. It is recommended that this behavior be > configurable on a connection basis within each application when > > > > Loughney (editor) March 3, 2003 > [Page 8] > > > > > > Internet-Draft > August 28, 2003 > > > available. It is noted that a number of applications do not work > with addresses generated with this method, while other applications > work quite well with them. > > 4.5.4 Default Address Selection for IPv6 > > Default Address Selection for IPv6 [DEFADDR] SHOULD be > supported, if > a node has more than one IPv6 address per interface or a node has > more that one IPv6 interface (physical or logical) configured. > > If supported, the rules specified in the document MUST be > implemented. A node needs to belong to one site, however > there is no > requirement that a node be able to belong to more than one site. > > This draft has been approved as a proposed standard. > > 4.5.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] > is the standard stateful address configuration protocol. > See section > 5.3 for details on DHCP. Stateful Address Autoconfiguration SHOULD be supported when the "M" bit is set and Stateful Address Parameter Configuration MUST be supported when the "O" bit is set. The default method for Address Autoconfiguration is the Stateless model and a MUST for all nodes to support, and the Stateful model when the M bit is set SHOULD be supported. If nodes will not participate in Stateful Address Autoconfiguration then they have no need to comply with the SHOULD when an M bit is set. > > 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 > > Multicast Listener Discovery [RFC-2710] MUST be supported by nodes > supporting multicast applications. A primary IPv6 multicast > application is Neighbor Discovery (all those solicited-node mcast > addresses must be joined). > > When MLDv2 [MLDv2] has been completed, it SHOULD take > precedence over > MLD. > > 5. Transport Layer and DNS > > 5.1 Transport Layer > > 5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 > > This specification MUST be supported if jumbograms are implemented > [RFC-2675]. One open issue is if this document needs to > be updated, > as it refers to an obsoleted document. We cannot require a MUST for this until a new document is generated this is telling implementers to implement functions that are potentially out of date. This also has no wide use or testing that this mail is aware of at this time? > > 5.2 DNS > > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152] > and [RFC-3363] MAY be supported. Not all nodes will need > to resolve > addresses. Note that RFC 1886 is currently being updated > [RFC-1886- > BIS]. DNS "use" is a MUST for correct node operation. MAY is absurd. > > > > Loughney (editor) March 3, 2003 > [Page 9] > > > > > > Internet-Draft > August 28, 2003 > > > 5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 > > RFC 2732 MUST be supported if applications on the node use URL's. > > 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > > An IPv6 node that does not include an implementation of > DHCP will be > unable to obtain any IPv6 addresses aside from link-local addresses > when it is connected to a link over which it receives a router > advertisement with the 'M' flag (Managed address configuration) set > and which contains no prefixes advertised for Stateless Address > Autoconfiguration (see section 4.5.2). An IPv6 node that receives a > router advertisement with the 'M' flag set and that contains > advertised prefixes will configure interfaces with both stateless > autoconfiguration addresses and addresses obtained through DHCP. > > For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' > flag set (see > section 5.5.3 of RFC2462). In addition, in the absence of > a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > > For IPv6 Nodes that do not implement DHCP, the 'M' flag of a Router > Advertisement can be ignored. Furthermore, in the absence of a > router, this type of node is not required to initiate DHCP. > > An IPv6 node that does not include an implementation of > DHCP will be > unable to dynamically obtain any IPv6 addresses aside from > link-local > addresses when it is connected to a link over which it receives a > router advertisement with the 'M' flag (Managed address > configuration) set and which contains no prefixes advertised for > Stateless Address Autoconfiguration (see section 4.5.2). In this > situation, the IPv6 Node will be unable to communicate with other > off-link nodes unless a global or site-local IPv6 address > is manually > configured. > > > 6. IPv4 Support and Transition > > IPv6 nodes MAY support IPv4. I disagree but why is this part of the node requirements. If it is it should be a SHOULD. Coexistence with IPv6 and IPv4 will be the norm for most nodes for some time. > > 6.1 Transition Mechanisms > > IPv6 nodes SHOULD use native address instead of transition-based > addressing. > > 6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 > > If an IPv6 node implement dual stack and/or tunneling, then RFC2893 > > > > Loughney (editor) March 3, 2003 > [Page 10] > > > > > > Internet-Draft > August 28, 2003 > > > MUST be supported. > > This document is currently being updated. > > 7. Mobility > > Currently, the MIPv6 specification [MIPv6] is nearing completion. > Mobile IPv6 places some requirements on IPv6 nodes. This > document is > not meant to prescribe behaviors, but to capture the consensus of > what should be done for IPv6 nodes with respect to Mobile IPv6. > > 7.1 Mobile IP > > Mobile IPv6 [MIPv6] specification defines requirements for the > following types of nodes: > > - mobile nodes > - correspondent nodes with support for route optimization > - home agents > - all IPv6 routers > > Hosts MAY support mobile node functionality. This should be SHOULD. The changing specs are not or can be an issue but this document is riddled with changing specs. > > Hosts SHOULD support route optimization requirements for > correspondent nodes. Routers do not need to support route > optimization. > > Routers MAY support home agent functionality. Routers SHOULD support the HA is correct effort. Otherwise MIPv6 don't work. > > Routers SHOULD support the requirements set for all IPv6 routers. > > 7.2 Securing Signaling between Mobile Nodes and Home Agents > > The security mechanisms described in [MIPv6-HASEC] MUST be > supported > by nodes implementing mobile node or home agent functionality > specified in Mobile IP [MIPv6]. > > 7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473 > > Generic Packet Tunneling [RFC-2473] MUST be suppored for nodes > implementing mobile node functionality or Home Agent > functionality of > Mobile IP [MIPv6]. > > > 8. Security > > This section describes the specification of IPsec for the > IPv6 node. > Other issues that IPsec cannot resolve are described in > the security > > > > Loughney (editor) March 3, 2003 > [Page 11] > > > > > > Internet-Draft > August 28, 2003 > > > considerations. > > 8.1 Basic Architecture > > Security Architecture for the Internet Protocol [RFC-2401] MUST be > supported. > > 8.2 Security Protocols > > ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. > > 8.3 Transforms and Algorithms > > Current IPsec RFCs specify the support of certain transforms and > algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and > HMAC-MD5-96. > The requirements for these are discussed first, and then additional > algorithms 3DES-CBC, AES-128-CBC, and HMAC-SHA-256-96 are > discussed. > > NULL encryption algorithm [RFC-2410] MUST be supported for > providing > integrity service and also for debugging use. The "ESP > DES-CBC Cipher > Algorithm With Explicit IV" [RFC-2405] MUST be supported. Security > issues related to the use of DES are discussed in [DESDIFF], > [DESINT], [DESCRACK]. It is currently viewed as an inherently weak > algorithm, and no longer fulfills its intended role. It is still > required by the existing IPsec RFCs, however. This document > recommends the use of ESP DES-CBC only where interoperability is > required with old implementations supporting DES-CBC. > > The NULL authentication algorithm [RFC-2406] MUST be > supported within > ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- > 2404] MUST be supported. The Use of HMAC-MD5-96 within AH and ESP, > described in [RFC-2403] MUST be supported. An implementer > MUST refer > to Keyed-Hashing for Message Authentication [RFC-2104]. > > 3DES-CBC does not suffer from the issues related to > DES-CBC. 3DES-CBC > and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be supported. AES- > 128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is > expected to > be a widely available, secure algorithm that is required for > interoperability. It is not required by the current IPsec RFCs, > however. > > The "HMAC-SHA-256-96 Algorithm and Its Use With IPsec" [ipsec-ciph- > sha-256] MAY be supported. > > 8.4 Key Management Methods > > Manual keying MUST be supported Manual keying SHOULD be supported (this is changing in MIPv6 it appears)?? > > > > > Loughney (editor) March 3, 2003 > [Page 12] > > > > > > Internet-Draft > August 28, 2003 > > > IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast > traffic. Where key refresh, anti-replay features of AH and ESP, or > on-demand creation of SAs is required, automated keying MUST be > supported. Note that the IPsec WG is working on the > successor to IKE > [SOI]. Key management methods for multicast traffic are also being > worked on by the MSEC WG. > > > 9. Router Functionality > > This section defines general considerations for IPv6 nodes that act > as routers. It is for future study if this document, or a separate > document is needed to fully define IPv6 router requirements. > Currently, this section does not discuss routing protocols. > > 9.1 General > > 9.1.1 IPv6 Router Alert Option - RFC2711 > > The Router Alert Option [RFC-2711] MUST be supported by nodes that > perform packet forwarding at the IP layer (i.e. - the node is a > router). > > 9.1.2 Neighbor Discovery for IPv6 - RFC2461 > > Sending Router Advertisements and processing Router > Solicitation MUST > be supported. > > 10. Network Management > > Network Management, MAY be supported by IPv6 nodes. However, for > IPv6 nodes that are embedded devices, network management may be the > only possibility to control these hosts. > > 10.1 MIBs > > In a general sense, MIBs SHOULD be supported by nodes that > support a > SNMP agent. > > 10.1.1 IP Forwarding Table MIB > > Support for this MIB does not imply that IPv4 or IPv4 specific > portions of this MIB be supported. > > 10.1.2 Management Information Base for the Internet Protocol (IP) > > Support for this MIB does not imply that IPv4 or IPv4 specific > portions of this MIB be supported. > > > > Loughney (editor) March 3, 2003 > [Page 13] > > > > > > Internet-Draft > August 28, 2003 > > > 11. Security Considerations > > This draft does not affect the security of the Internet, but > implementations of IPv6 are expected to support a minimum set of > security features to ensure security on the Internet. "IP Security > Document Roadmap" [RFC-2411] is important for everyone to read. > > The security considerations in RFC2460 describes the following: > > The security features of IPv6 are described in the Security > Architecture for the Internet Protocol [RFC-2401]. > > For example, specific protocol documents and applications > may require > the use of additional security mechanisms. > > The use of ICMPv6 without IPsec can expose the nodes in question to > various kind of attacks including Denial-of-Service, Impersonation, > Man-in-the-Middle, and others. Note that only manually keyed IPsec > can protect some of the ICMPv6 messages that are related to > establishing communications. This is due to > chicken-and-egg problems > on running automated key management protocols on top of > IP. However, > manually keyed IPsec may require a large number of SAs in order to > run on a large network due to the use of many addresses > during ICMPv6 > Neighbor Discovery. > > The use of wide-area multicast communications has an increased risk > from specific security threats, compared with the same threats in > unicast [MC-THREAT]. > > An implementer should also consider the analysis of anycast > [ANYCAST]. > > This document requires an Applicability Statement for implementors. Regards, /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 Tue Mar 18 11:34:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IJY57f023828; Tue, 18 Mar 2003 11:34:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IJY4N4023827; Tue, 18 Mar 2003 11:34:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IJY17f023820 for ; Tue, 18 Mar 2003 11:34:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IJY9jO019889 for ; Tue, 18 Mar 2003 11:34:09 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21174 for ; Tue, 18 Mar 2003 12:34:03 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:33:59 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:33:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:33:58 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:33:57 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2IJXsSo136218 for ; Tue, 18 Mar 2003 20:33:55 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2IJXpxD121076 for ; Tue, 18 Mar 2003 20:33:53 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27370 from ; Tue, 18 Mar 2003 20:33:47 +0100 Message-Id: <3E7763E3.9EB2E7DF@hursley.ibm.com> Date: Tue, 18 Mar 2003 19:22:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The co-authors' plan is to revise the draft according to the comments in hand (mainly Pekka's) and offer the revision to the WG chairs as the response to the WG last call. I also discussed with a few security people yesterday, and I will ask them to have a look at the revised security considerations before the draft hits the IESG reading list. Brian -------------------------------------------------------------------- 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 Mar 18 11:50:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IJoD7f024134; Tue, 18 Mar 2003 11:50:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IJoDvX024133; Tue, 18 Mar 2003 11:50:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IJoA7f024126 for ; Tue, 18 Mar 2003 11:50:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IJoIcU001196 for ; Tue, 18 Mar 2003 11:50:18 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16504 for ; Tue, 18 Mar 2003 12:50:12 -0700 (MST) From: matthew.ford@bt.com Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:49:50 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:49:31 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:49:31 Z Received: from cbibipnt05.hc.bt.com ([193.113.57.20] [193.113.57.20]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:49:31 Z Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id ; Tue, 18 Mar 2003 19:49:39 -0000 Message-Id: To: ipng@sunroof.eng.sun.com Subject: RE: RESEND: slides Date: Tue, 18 Mar 2003 19:49:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk apologies for spamming the list with this query twice. seems i am not receiving mail to the list - i guess as a result of the 'too many hops' problem recently announced. i am chasing this internally now. mat. > -----Original Message----- > From: Ford,M,Mat,DEN5 FORDM5 R > Sent: 18 March 2003 09:26 > To: 'ipng@sunroof.eng.sun.com' > Subject: RESEND: slides > > > > > > -----Original Message----- > > From: Ford,M,Mat,DEN5 FORDM5 R > > Sent: 17 March 2003 19:57 > > To: 'ipng@sunroof.eng.sun.com' > > Subject: slides > > > > > > will the slides from today's meeting be made available somewhere? > > > > mat. > > > -------------------------------------------------------------------- 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 Mar 18 12:21:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IKLC7f024524; Tue, 18 Mar 2003 12:21:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IKLCFg024523; Tue, 18 Mar 2003 12:21:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IKL97f024516 for ; Tue, 18 Mar 2003 12:21:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IKLHcU011582 for ; Tue, 18 Mar 2003 12:21:17 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11208 for ; Tue, 18 Mar 2003 13:21:06 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 20:19:46 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:17:34 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:17:33 Z Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 19:17:33 Z Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2IJHVKn025081 for ; Tue, 18 Mar 2003 11:17:31 -0800 (PST) Received: from SIVAV.qualcomm.com (vpn-10-50-0-10.qualcomm.com [10.50.0.10]) by crowley.qualcomm.com (8.12.8/8.12.5/1.0) with ESMTP id h2IJHTZJ026847 for ; Tue, 18 Mar 2003 11:17:29 -0800 (PST) Message-Id: <4.3.2.7.2.20030318111531.01419cd8@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Mar 2003 11:17:27 -0800 To: ipng@sunroof.eng.sun.com From: Siva Veerepalli Subject: Updates to PPPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The current work items in the wg charter and Margaret's presentation on document status in the WG meeting shows PPPv6 as one of the items. Could someone clarify what changes/updates are being considered for IPv6 over PPP rfc? Are they technical or editorial/clarification of existing text? I meant to send this mail to the rfc authors, but their email addresses on the rfc are not current. Thanks, Siva -------------------------------------------------------------------- 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 Mar 18 13:46:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ILk97f025658; Tue, 18 Mar 2003 13:46:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ILk9Nt025657; Tue, 18 Mar 2003 13:46:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ILk67f025650 for ; Tue, 18 Mar 2003 13:46:06 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ILkEcU017099 for ; Tue, 18 Mar 2003 13:46:14 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20636 for ; Tue, 18 Mar 2003 13:46:08 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:38:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:38:20 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:38:20 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:38:19 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA08905; Tue, 18 Mar 2003 21:38:15 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA02171; Tue, 18 Mar 2003 21:38:15 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2ILcF928884; Tue, 18 Mar 2003 21:38:15 GMT Date: Tue, 18 Mar 2003 21:38:15 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: dns discovery for agenda? [Re: chairs and charter] Message-Id: <20030318213815.GB28564@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com, dnsop@cafax.se References: <20030317060620.GA24236@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 18, 2003 at 05:40:02AM +0100, Johan Ihren wrote: > > Someone has to implement these things, burn code into proms and ship > products. That process is not simplified by having several alternate > mechanisms available. From an implementation point of view it would be > much preferable to have just one and be done with it. And if you only > have one, it had better be somewhat more generic than RA. Hi Johan, I think we're talking about two mechanisms, not "several", one geared to stateful environments (which is fine, and of course necessary), the other to stateless environments. The RA method for stateless (for which a draft was proposed last year, though I think it expired) is the only stateless method on (or near :) to the table now, but the question is more general: do we want to mandate a DHCPv6 server to be present to have DNS functionality in statelessly configuring IPv6 nodes? > With all due respect, I think this is short sighted. Today you almost > cannot buy a DSL router for home use that doesn't have an integrated > DHCP server, among all kinds of other strange stuff. To make a future > equivalents of such devices also talk DHCPv6 is clearly possible. Sure. But that's then still a lot of DHCP code for just DNS discovery (if DNS discovery is all that is required of the DHCPv6 server, and the node doesn't need other DHCPv6 options). Also, often the home DSL router can perform the resolver function. This throws up a possibility for such home devices for the RA message having an option to say "use me for DNS", which would be simpler, but only apply to a subset of cases. > The more interesting issue that I think we should focus on is *how do > you configure* the device to make correct announcements of where the > recursive nameservice is located. And if we stay with the DSL- > whatever-in-a-home example it seems rather clear that that > configuration issue is exactly the same regardless of whether the > stuff is sent out piggybacked as an RA option or via DHCPv6. Agreed. The "use me" option above would circumvent that need (for that specific case), but I accept it's still extra code. > But in the particular case of *discovery* mechanisms I still think > that this is a mistake that needs to be rectified. I appreciate people may be concerend of creeping featurism, but I think it's a fairly clear minimum requirement for a node to have basic stateless autoconf and DNS config (ref. Jim's comment to the list on DNS "MUST"). Maybe others don't see such a scenario being common. Maybe a node will also want other DHCPv6 options, like preferred prefix, time, NIS, whatever, but these are beyond the basic need for connectivity and name resolution. > And the reason is that discovery is part of "bootstrapping" a device > to become a first class member of the network. "Software upgrades" > take place after bootstrapping so mucking with discovery will always > be extremely expensive for installed devices. Not to mention that when > the device and the infrastructure don't share the same view on > discovery things will break in ugly ways. Appreciated. If dnsop doesn't want to consider this item, so be it, but it has, as I understand it, been punted from the IPv6 Charter to dnsop (rightly :) so I feel it's worth pressing the question at this point. 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 Tue Mar 18 13:46:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ILkW7f025668; Tue, 18 Mar 2003 13:46:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ILkVgG025667; Tue, 18 Mar 2003 13:46:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ILkP7f025660 for ; Tue, 18 Mar 2003 13:46:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ILkYcU017319 for ; Tue, 18 Mar 2003 13:46:34 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26125 for ; Tue, 18 Mar 2003 14:46:27 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:46:23 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:46:22 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:46:22 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:46:20 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2ILjsOI086074; Tue, 18 Mar 2003 22:45:55 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2ILjs4S251004; Tue, 18 Mar 2003 22:45:54 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27154 from ; Tue, 18 Mar 2003 22:45:52 +0100 Message-Id: <3E77934F.B34495E5@hursley.ibm.com> Date: Tue, 18 Mar 2003 22:44:47 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Bound, Jim" Cc: ipng@sunroof.eng.sun.com Subject: 5.2 DNS [Re: Nodes Requirements Input] References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD22@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Bound, Jim" wrote: ... > > > > 5.2 DNS > > > > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152] > > and [RFC-3363] MAY be supported. Not all nodes will need > > to resolve > > addresses. Note that RFC 1886 is currently being updated > > [RFC-1886- > > BIS]. > > DNS "use" is a MUST for correct node operation. MAY is absurd. Why would a thermostat need to resolve names? Brian -------------------------------------------------------------------- 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 Mar 18 13:51:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ILpd7f026008; Tue, 18 Mar 2003 13:51:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ILpd8f026007; Tue, 18 Mar 2003 13:51:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ILpZ7f025998 for ; Tue, 18 Mar 2003 13:51:35 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ILphjO008639 for ; Tue, 18 Mar 2003 13:51:43 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26280 for ; Tue, 18 Mar 2003 13:51:38 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:51:32 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:48:58 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:51:32 Z Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 21:51:30 Z Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 18 Mar 2003 13:51:27 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Mar 2003 13:51:26 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Mar 2003 13:51:27 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Mar 2003 13:51:26 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Mar 2003 13:51:27 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 18 Mar 2003 13:51:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on IPv6 source address selection socket API Date: Tue, 18 Mar 2003 13:51:22 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on IPv6 source address selection socket API Thread-Index: AcLca9j+SXVWlXJUQM2xqXFnxF82DARKowZg From: "Dave Thaler" To: "Samita Chakrabarti" , Cc: , , X-OriginalArrivalTime: 18 Mar 2003 21:51:24.0747 (UTC) FILETIME=[8553D1B0:01C2ED98] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2ILpZ7f026001 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've read this document, and I would like to see it accepted as a WG document and charter item. Comments on the current text: Section 3 > It is recommended that the application does a getsockopt() prior > calling to setsockopt() call so that it can save the existing > source address preference value, in the cases when the application > might need to restore the preferences. I think the above paragraph is unneeded and confuses the issue. Setting the flags to 0 will restore the system default behavior. If the app is using multiple values at different times, the behavior is really up to the app, and the issue is not specific to this socket option. RFC 2553 etc do not contain a similar statement for other socket options which have the same issue. I'd suggest deleting this paragraph. Section 4 > The above flags are ignored for the AF_INET address family. If a > returned address is an IPv4 address (either as AF_INET6 when > AI_V4MAPPED, or as AF_INET) then the source preference flags have > no effect. If someone implements Mobile IPv4, wouldn't the HOME/COA flags be applicable to IPv4 source addresses? Section 7: > Is there a need for REQUIRE flags in addition to or instead of the > PREFER flags? Note that in general it isn't possible to verify > that a requirement can be satisfied until sendto() or connect() > (when the destination address is known) thus this would result > in late errors being reported to the application. I agree "require" flags would be nice. For example, if an app requires a particular type of address and there are no such addresses available, it may be better to fail the setsockopt than either failing all sends or using another type of address instead. If the consensus is go this way, it would be better in my opinion, to split the socket option into 3 separate options (HOME/COA, TMP/PUBLIC, and CGA/NONCGA). For each of those three options, you'd have 5 values: Require A Prefer A Use system default rules Prefer B Require B I also saw a couple of typos/grammar issues which I will just send to the authors. -Dave -------------------------------------------------------------------- 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 Mar 18 14:50:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IMoa7f027303; Tue, 18 Mar 2003 14:50:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IMoatE027302; Tue, 18 Mar 2003 14:50:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IMoV7f027295 for ; Tue, 18 Mar 2003 14:50:32 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2IMoTP12900; Tue, 18 Mar 2003 23:50:30 +0100 (MET) Date: Tue, 18 Mar 2003 23:46:29 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Draft on IPv6 source address selection socket API To: Dave Thaler Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the above paragraph is unneeded and confuses the issue. > Setting the flags to 0 will restore the system default behavior. > If the app is using multiple values at different times, the behavior > is really up to the app, and the issue is not specific to this > socket option. RFC 2553 etc do not contain a similar statement > for other socket options which have the same issue. I'd suggest > deleting this paragraph. The issue is that by having PREFER_FOO and PREFER_NOTFOO flags is that the absense of having any of PREFER_FOO and PREFR_NOTFOO flags set in a setsockopt nothing about the "foo" state can change. If it did change they the application couldn't change the state for bar independently of foo. A result of this is that a setsockopt with zero flags can have no effect. So unless we change the approach we'd need a separate mechanism for resetting to the default. > If someone implements Mobile IPv4, wouldn't the HOME/COA flags > be applicable to IPv4 source addresses? Could be. We can relax this to allow it to work for IPv4. > I agree "require" flags would be nice. For example, if an app requires > a particular type of address and there are no such addresses available, > it may be better to fail the setsockopt than either failing all sends or > using another type of address instead. With the complications that some failures will appear late e.g. due to a source address of the type not (or no longer) being available on the outbound interface. Another complication is that I don't know what it means to say REQUIRE_HOA or REQUIRE_COA if the node isn't currently mobile or when it is at home. The softer notion of preferences avoids this, but addition validation ("is this address a HoA") adds that complication back in I think. 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 Mar 18 15:01:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IN1K7f027496; Tue, 18 Mar 2003 15:01:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2IN1KIr027495; Tue, 18 Mar 2003 15:01:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2IN1G7f027488 for ; Tue, 18 Mar 2003 15:01:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2IN1PcU016988 for ; Tue, 18 Mar 2003 15:01:25 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19688 for ; Tue, 18 Mar 2003 16:01:19 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:01:19 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:01:16 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:01:16 Z Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:01:15 Z Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 18 Mar 2003 15:01:01 -0800 Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Mar 2003 15:01:13 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 18 Mar 2003 15:01:12 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 18 Mar 2003 15:01:12 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 18 Mar 2003 15:01:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on IPv6 source address selection socket API Date: Tue, 18 Mar 2003 15:01:08 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on IPv6 source address selection socket API Thread-Index: AcLtoNS/ixr9X/YLQSGzspyhkhtKqwAAELZw From: "Dave Thaler" To: "Erik Nordmark" Cc: "Samita Chakrabarti" , , , X-OriginalArrivalTime: 18 Mar 2003 23:01:09.0316 (UTC) FILETIME=[43866040:01C2EDA2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2IN1H7f027489 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > > I think the above paragraph is unneeded and confuses the issue. > > Setting the flags to 0 will restore the system default behavior. > > If the app is using multiple values at different times, the behavior > > is really up to the app, and the issue is not specific to this > > socket option. RFC 2553 etc do not contain a similar statement > > for other socket options which have the same issue. I'd suggest > > deleting this paragraph. > > The issue is that by having PREFER_FOO and PREFER_NOTFOO flags > is that the absense of having any of PREFER_FOO and PREFR_NOTFOO flags > set in a setsockopt nothing about the "foo" state can change. > If it did change they the application couldn't change the state for bar > independently of foo. The spec doesn't currently discuss this issue, but this is what I meant by "confuses the issue". It currently implies that setting the flag to PREFER_FOO will undo your orthogonal PREFER_BAR, since it implies that setting PREFER_NOTFOO will undo a previous PREFER_FOO. This is actually another argument for splitting the option into 3 separate options. Then it's clear that a set overrides any previous set, and doesn't interfere with the other 2 orthogonal options. It also provides a reasonable meaning for the value 0. As presently worded, it's unclear what the meaning of value 0 is. > > I agree "require" flags would be nice. For example, if an app requires > > a particular type of address and there are no such addresses available, > > it may be better to fail the setsockopt than either failing all sends or > > using another type of address instead. > > With the complications that some failures will appear late e.g. due to > a source address of the type not (or no longer) being available on > the outbound interface. Right. > Another complication is that I don't know what it means to > say REQUIRE_HOA or REQUIRE_COA if the node isn't > currently mobile or when it is at home. > The softer notion of preferences avoids this, but addition > validation ("is this address a HoA") adds that complication > back in I think. Agree. My personal vote is that it's still worthwhile. Let's see what others say. -Dave -------------------------------------------------------------------- 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 Mar 18 15:13:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INDw7f028010; Tue, 18 Mar 2003 15:13:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2INDv0D028009; Tue, 18 Mar 2003 15:13:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INDr7f027999 for ; Tue, 18 Mar 2003 15:13:53 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2INDsP15702; Wed, 19 Mar 2003 00:13:54 +0100 (MET) Date: Wed, 19 Mar 2003 00:09:54 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Draft on IPv6 source address selection socket API To: Dave Thaler Cc: Erik Nordmark , Samita Chakrabarti , ipng@sunroof.eng.sun.com, Julien.Laganier@Sun.COM, samita@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One other thing I forgot is that, since we need to pass flags to getaddrinfo as well as the TCP/IP stack, there is a need to fit all the flags (whether there are only prefer or prefer+require flags) into the flag name space for getaddrinfo. This has some implication on the number of flags one can invent. 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 Mar 18 15:38:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INct7f028665; Tue, 18 Mar 2003 15:38:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2INcs2b028664; Tue, 18 Mar 2003 15:38:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INcp7f028657 for ; Tue, 18 Mar 2003 15:38:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2INcxjO017226 for ; Tue, 18 Mar 2003 15:38:59 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06550 for ; Tue, 18 Mar 2003 16:38:53 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:38:52 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:38:51 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:38:51 Z Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:38:50 Z Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h2INcjZ00598; Tue, 18 Mar 2003 15:38:45 -0800 (PST) Message-Id: <200303182338.h2INcjZ00598@gamma.isi.edu> To: IETF-Announce:; Subject: RFC 3493 on Basic Socket Interface Extensions for IPv6 Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 18 Mar 2003 15:38:44 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3493 Title: Basic Socket Interface Extensions for IPv6 Author(s): R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens Status: Informational Date: March 2003 Mailbox: gilligan@intransa.com, sethomso@cisco.com, Jim.Bound@hp.com, Jack.McCann@hp.com Pages: 39 Characters: 82570 Obsoletes: 2553 I-D Tag: draft-ietf-ipngwg-rfc2553bis-10.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3493.txt The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. This document is a product of the IP Version 6 Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030318153707.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3493 --OtherAccess Content-Type: Message/External-body; name="rfc3493.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030318153707.RFC@RFC-EDITOR.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 Tue Mar 18 15:45:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INjV7f028916; Tue, 18 Mar 2003 15:45:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2INjVho028915; Tue, 18 Mar 2003 15:45:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INjS7f028908 for ; Tue, 18 Mar 2003 15:45:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2INjZcU003162 for ; Tue, 18 Mar 2003 15:45:36 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00160 for ; Tue, 18 Mar 2003 16:45:30 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:45:29 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:45:29 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:45:28 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:45:28 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9C7A123D2; Tue, 18 Mar 2003 18:45:27 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Mar 2003 18:45:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] Date: Tue, 18 Mar 2003 18:45:25 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD23@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.2 DNS [Re: Nodes Requirements Input] Thread-Index: AcLtl9UuPuTJaOI3ToeS7t3ik+453wAEHFiQ From: "Bound, Jim" To: "Brian E Carpenter" Cc: X-OriginalArrivalTime: 18 Mar 2003 23:45:26.0099 (UTC) FILETIME=[73174A30:01C2EDA8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2INjS7f028909 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agreed. But how can a node find an address without MUST DNS. The point is that a requirement to use is based on the situation. My point last night. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, March 18, 2003 4:45 PM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: 5.2 DNS [Re: Nodes Requirements Input] > > > "Bound, Jim" wrote: > ... > > > > > > 5.2 DNS > > > > > > DNS, as described in [RFC-1034], [RFC-1035], > [RFC-1886], [RFC-3152] > > > and [RFC-3363] MAY be supported. Not all nodes will need to > > > resolve > > > addresses. Note that RFC 1886 is currently being updated > > > [RFC-1886- > > > BIS]. > > > > DNS "use" is a MUST for correct node operation. MAY is absurd. > > Why would a thermostat need to resolve names? > > Brian > -------------------------------------------------------------------- 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 Mar 18 15:46:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INka7f028948; Tue, 18 Mar 2003 15:46:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2INkabE028947; Tue, 18 Mar 2003 15:46:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2INkW7f028940 for ; Tue, 18 Mar 2003 15:46:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2INkecU003664 for ; Tue, 18 Mar 2003 15:46:40 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19700 for ; Tue, 18 Mar 2003 15:46:34 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:46:34 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:43:59 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:46:33 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 18 Mar 2003 23:46:33 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9AFC5A2C for ; Tue, 18 Mar 2003 18:46:32 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Mar 2003 18:46:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: Nodes Requirements Input Date: Tue, 18 Mar 2003 18:46:32 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD24@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nodes Requirements Input Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8PgAAq4AgA= From: "Bound, Jim" To: X-OriginalArrivalTime: 18 Mar 2003 23:46:32.0474 (UTC) FILETIME=[9AA74FA0:01C2EDA8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2INkW7f028941 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RESEND. I am hearing not all got this for some reason. /jim -----Original Message----- From: Bound, Jim Sent: Tuesday, March 18, 2003 2:08 PM To: 'ipng@sunroof.eng.sun.com' Subject: Nodes Requirements Input WG, For any show of hands for Thursday a.m. per any discussion of Node Requirements I believe to guage the initial consensus (all meetings must be ratified by follow email and hum is bad show of hands is better) here are some questions that also should be asked. How many people have read and understand RFC 2461? How many people have read and understand RFC 2462? Then the actual question regarding the topic at hand. Below is further input to the Node Requirements document. This document should not be standards track but possibly a BCP? It will change. But I don't believe we need this document except in form suggested further below in this mail. I also believe as I said at WG meeting Monday night I fear we need to determine a set of node requirements documents and a one size fits all will not satisfy all nodes. As Bob Hinden suggested possibly based on "services" as opposed to node types. Also when we did 1122 and 1123 many years ago and then some of us actually implemented those it took us years to get the MAYs done for users and even some SHOULDs. Like it or not implementors are affected by these 2119 terms. Also the specs to day are far better, more robust, more peer review etc. There is less of a need for 1122 and 1123 requirements from the early to mid 80's specifications. We also now have many interoperability tests for IPv6 and it is clear to any vendor that does not pass them and to the market for IPv6 bids. That is the ultimate authority did a vendors node pass the interoperability tests in the public domain. Lastly we need to make sure and listen to who wants what in an addendum to our IPv6 specs and listen to why? More input to the requirements below. > -----Original Message----- > From: Bound, Jim > Sent: Tuesday, March 18, 2003 10:53 AM > To: Bound, Jim > Subject: node reqs prep > > > > 3. Sub-IP Layer > > An IPv6 node must follow the RFC related to the link-layer that is > sending packet. By definition, these specifications are required > based upon what layer-2 is used. In general, it is reasonable to > be > a conformant IPv6 node and NOT support some legacy interfaces. > > As IPv6 is run over new layer 2 technologies, it is expected that > new > specifications will be issued. This section highlights some major > layer 2 technologies and is not intended to be complete. Why are we producing an incomplete document for standards track in IPv6? > > 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 > > Transmission of IPv6 Packets over Ethernet Networks [RFC-2464] MUST > be supported for nodes supporting Ethernet interfaces. > > 3.2 IP version 6 over PPP - RFC2472 > > IPv6 over PPP [RFC-2472] MUST be supported for nodes that use PPP. > > 3.3 IPv6 over ATM Networks - RFC2492 > > IPv6 over ATM Networks [RFC2492] MUST be supported for nodes > supporting ATM interfaces. Additionally, the specification states: > > A minimally conforming IPv6/ATM driver SHALL support the PVC > mode > of operation. An IPv6/ATM driver that supports the full SVC mode > SHALL also support PVC mode of operation. > > 4. IP Layer > > 4.1 Internet Protocol Version 6 - RFC2460 > > The Internet Protocol Version 6 is specified in [RFC-2460]. This > specification MUST be supported. > > Unrecognized options in Hop-by-Hop Options or Destination Options > extensions MUST be processed as described in RFC 2460. > > The node MUST follow the packet transmission rules in RFC 2460. > > Nodes MUST always be able to receive fragment headers. However, if > it > > > > Loughney (editor) March 3, 2003 > [Page 5] > > > > > > Internet-Draft > August 28, 2003 > > > does not implement path MTU discovery it may not need to send > fragment headers. However, nodes that do not implement > transmission > of fragment headers need to impose limitation to payload size of > layer 4 protocols. > > The capability of being a final destination MUST be supported, > whereas the capability of being an intermediate destination MAY be > supported (i.e. - host functionality vs. router functionality). > > RFC 2460 specifies extension headers and the processing for these > headers. > > A full implementation of IPv6 includes implementation of the > following extension headers: Hop-by-Hop Options, Routing (Type > 0), > Fragment, Destination Options, Authentication and Encapsulating > Security Payload. [RFC2460] > > An IPv6 node MUST be able to process these headers. It should be > noted that there is some discussion about the use of Routing > Headers > and possible security threats [IPv6-RH] caused by them. > > 4.2 Neighbor Discovery for IPv6 - RFC2461 > > Neighbor Discovery SHOULD be supported. RFC 2461 states: > > "Unless specified otherwise (in a document that covers operating > IP over a particular link type) this document applies to all > link > types. However, because ND uses link-layer multicast for some of > its services, it is possible that on some link types (e.g., NBMA > links) alternative protocols or mechanisms to implement those > services will be specified (in the appropriate document covering > the operation of IP over a particular link type). The services > described in this document that are not directly dependent on > multicast, such as Redirects, Next-hop determination, Neighbor > Unreachability Detection, etc., are expected to be provided as > specified in this document. The details of how one uses ND on > NBMA links is an area for further study." > > Some detailed analysis of Neighbor discovery follows: > > Router Discovery is how hosts locate routers that reside on an > attached link. Router Discovery MUST be supported for > implementations. However, an implementation MAY support disabling > this function. > > Prefix Discovery is how hosts discover the set of address prefixes > that define which destinations are on-link for an attached link. > Prefix discovery MUST be supported for implementations. However, > the > > > > Loughney (editor) March 3, 2003 > [Page 6] > > > > > > Internet-Draft > August 28, 2003 > > > implementation MAY support the option of disabling this function. > > Neighbor Unreachability Detection (NUD) MUST be supported for all > paths between hosts and neighboring nodes. It is not required for > paths between routers. It is required for multicast. However, when > a > node receives a unicast Neighbor Solicitation (NS) message > (that may > be a NUD's NS), the node MUST respond to it (i.e. send a unicast > Neighbor Advertisement). > > Duplicate Address Detection MUST be supported (RFC2462 section 5.4 > specifies DAD MUST take place on all unicast addresses). > > Sending Router Solicitation MUST be supported for host > implementation, but MAY support a configuration option to disable > this functionality. > > Receiving and processing Router Advertisements MUST be supported > for > host implementation s. However, the implementation MAY support the > option of disabling this function. The ability to > understand specific > Router Advertisements is dependent on supporting the specification > where the RA is specified. > > Sending and Receiving Neighbor Solicitation (NS) and Neighbor > Advertisement (NA) MUST be supported. NS and NA messages are > required > for Duplicate Address Detection (DAD). > > Redirect Function SHOULD be supported. If the node is a router, > Redirect Function MUST be supported. > > 4.3 Path MTU Discovery & Packet Size > > 4.3.1 Path MTU Discovery - RFC1981 > > Path MTU Discovery [RFC-1981] MAY be supported. Nodes with a link > MTU larger than the minimum IPv6 link MTU (1280 octets) can use > Path > MTU Discovery in order to discover the real path MTU. The relative > overhead of IPv6 headers is minimized through the use of longer > packets, thus making better use of the available bandwidth. > > The IPv6 specification [RFC-2460] states in chapter 5 that "a > minimal > IPv6 implementation (e.g., in a boot ROM) may simply > restrict itself > to sending packets no larger than 1280 octets, and omit > implementation of Path MTU Discovery." > > If Path MTU Discovery is not implemented then the sending packet > size > is limited to 1280 octets (standard limit in [RFC-2460]). > However, if > this is done, the host MUST be able to receive packets with size up > to the link MTU before reassembly. This is because the node at the > > > > Loughney (editor) March 3, 2003 > [Page 7] > > > > > > Internet-Draft > August 28, 2003 > > > other side of the link has no way of knowing less than the MTU is > accepted. > > 4.3.2 IPv6 Jumbograms - RFC2675 > > IPv6 Jumbograms [RFC2675] MAY be supported. > > 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 > > ICMPv6 [RFC-2463] MUST be supported. > > 4.5 Addressing > > Currently, there is discussion on-going on support for site-local > addressing. > > 4.5.1 IP Version 6 Addressing Architecture - RFC2373 > > The IPv6 Addressing Architecture [RFC-2373] MUST be supported. > Currently, this specification is being updated by [ADDRARCHv3]. This has changed now. ALso we need to reference Multi6 could affect this end result. > > 4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 > > IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. > This specification MUST be supported for nodes that are hosts. > > Nodes that are routers MUST be able to generate link local > addresses > as described in this specification. > > From 2462: > > The autoconfiguration process specified in this document applies > only to hosts and not routers. Since host autoconfiguration uses > information advertised by routers, routers will need to be > configured by some other means. However, it is expected that > routers will generate link-local addresses using the mechanism > described in this document. In addition, routers are expected to > successfully pass the Duplicate Address Detection procedure > described in this document on all addresses prior to assigning > them to an interface. > > Duplicate Address Detection (DAD) MUST be supported. > > 4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 > > Privacy Extensions for Stateless Address Autoconfiguration > [RFC-3041] > SHOULD be supported. It is recommended that this behavior be > configurable on a connection basis within each application when > > > > Loughney (editor) March 3, 2003 > [Page 8] > > > > > > Internet-Draft > August 28, 2003 > > > available. It is noted that a number of applications do not work > with addresses generated with this method, while other applications > work quite well with them. > > 4.5.4 Default Address Selection for IPv6 > > Default Address Selection for IPv6 [DEFADDR] SHOULD be supported, > if > a node has more than one IPv6 address per interface or a node has > more that one IPv6 interface (physical or logical) configured. > > If supported, the rules specified in the document MUST be > implemented. A node needs to belong to one site, however there is > no > requirement that a node be able to belong to more than one site. > > This draft has been approved as a proposed standard. > > 4.5.5 Stateful Address Autoconfiguration > > Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] > is the standard stateful address configuration protocol. See > section > 5.3 for details on DHCP. Stateful Address Autoconfiguration SHOULD be supported when the "M" bit is set and Stateful Address Parameter Configuration MUST be supported when the "O" bit is set. The default method for Address Autoconfiguration is the Stateless model and a MUST for all nodes to support, and the Stateful model when the M bit is set SHOULD be supported. If nodes will not participate in Stateful Address Autoconfiguration then they have no need to comply with the SHOULD when an M bit is set. > > 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 > > Multicast Listener Discovery [RFC-2710] MUST be supported by nodes > supporting multicast applications. A primary IPv6 multicast > application is Neighbor Discovery (all those solicited-node mcast > addresses must be joined). > > When MLDv2 [MLDv2] has been completed, it SHOULD take precedence > over > MLD. > > 5. Transport Layer and DNS > > 5.1 Transport Layer > > 5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 > > This specification MUST be supported if jumbograms are implemented > [RFC-2675]. One open issue is if this document needs to be > updated, > as it refers to an obsoleted document. We cannot require a MUST for this until a new document is generated this is telling implementers to implement functions that are potentially out of date. This also has no wide use or testing that this mail is aware of at this time? > > 5.2 DNS > > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], [RFC-3152] > and [RFC-3363] MAY be supported. Not all nodes will need to > resolve > addresses. Note that RFC 1886 is currently being updated > [RFC-1886- > BIS]. DNS "use" is a MUST for correct node operation. MAY is absurd. > > > > Loughney (editor) March 3, 2003 > [Page 9] > > > > > > Internet-Draft > August 28, 2003 > > > 5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 > > RFC 2732 MUST be supported if applications on the node use URL's. > > 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) > > An IPv6 node that does not include an implementation of DHCP will > be > unable to obtain any IPv6 addresses aside from link-local addresses > when it is connected to a link over which it receives a router > advertisement with the 'M' flag (Managed address configuration) set > and which contains no prefixes advertised for Stateless Address > Autoconfiguration (see section 4.5.2). An IPv6 node that receives a > router advertisement with the 'M' flag set and that contains > advertised prefixes will configure interfaces with both stateless > autoconfiguration addresses and addresses obtained through DHCP. > > For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP > upon the receipt of a Router Advertisement with the 'M' flag set > (see > section 5.5.3 of RFC2462). In addition, in the absence of > a router, > IPv6 Nodes that implement DHCP MUST attempt to use DHCP. > > For IPv6 Nodes that do not implement DHCP, the 'M' flag of a Router > Advertisement can be ignored. Furthermore, in the absence of a > router, this type of node is not required to initiate DHCP. > > An IPv6 node that does not include an implementation of DHCP will > be > unable to dynamically obtain any IPv6 addresses aside from > link-local > addresses when it is connected to a link over which it receives a > router advertisement with the 'M' flag (Managed address > configuration) set and which contains no prefixes advertised for > Stateless Address Autoconfiguration (see section 4.5.2). In this > situation, the IPv6 Node will be unable to communicate with other > off-link nodes unless a global or site-local IPv6 address > is manually > configured. > > > 6. IPv4 Support and Transition > > IPv6 nodes MAY support IPv4. I disagree but why is this part of the node requirements. If it is it should be a SHOULD. Coexistence with IPv6 and IPv4 will be the norm for most nodes for some time. > > 6.1 Transition Mechanisms > > IPv6 nodes SHOULD use native address instead of transition-based > addressing. > > 6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 > > If an IPv6 node implement dual stack and/or tunneling, then RFC2893 > > > > Loughney (editor) March 3, 2003 > [Page 10] > > > > > > Internet-Draft > August 28, 2003 > > > MUST be supported. > > This document is currently being updated. > > 7. Mobility > > Currently, the MIPv6 specification [MIPv6] is nearing completion. > Mobile IPv6 places some requirements on IPv6 nodes. This document > is > not meant to prescribe behaviors, but to capture the consensus of > what should be done for IPv6 nodes with respect to Mobile IPv6. > > 7.1 Mobile IP > > Mobile IPv6 [MIPv6] specification defines requirements for the > following types of nodes: > > - mobile nodes > - correspondent nodes with support for route optimization > - home agents > - all IPv6 routers > > Hosts MAY support mobile node functionality. This should be SHOULD. The changing specs are not or can be an issue but this document is riddled with changing specs. > > Hosts SHOULD support route optimization requirements for > correspondent nodes. Routers do not need to support route > optimization. > > Routers MAY support home agent functionality. Routers SHOULD support the HA is correct effort. Otherwise MIPv6 don't work. > > Routers SHOULD support the requirements set for all IPv6 routers. > > 7.2 Securing Signaling between Mobile Nodes and Home Agents > > The security mechanisms described in [MIPv6-HASEC] MUST be > supported > by nodes implementing mobile node or home agent functionality > specified in Mobile IP [MIPv6]. > > 7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473 > > Generic Packet Tunneling [RFC-2473] MUST be suppored for nodes > implementing mobile node functionality or Home Agent functionality > of > Mobile IP [MIPv6]. > > > 8. Security > > This section describes the specification of IPsec for the IPv6 > node. > Other issues that IPsec cannot resolve are described in > the security > > > > Loughney (editor) March 3, 2003 > [Page 11] > > > > > > Internet-Draft > August 28, 2003 > > > considerations. > > 8.1 Basic Architecture > > Security Architecture for the Internet Protocol [RFC-2401] MUST be > supported. > > 8.2 Security Protocols > > ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. > > 8.3 Transforms and Algorithms > > Current IPsec RFCs specify the support of certain transforms and > algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and > HMAC-MD5-96. > The requirements for these are discussed first, and then additional > algorithms 3DES-CBC, AES-128-CBC, and HMAC-SHA-256-96 are > discussed. > > NULL encryption algorithm [RFC-2410] MUST be supported for > providing > integrity service and also for debugging use. The "ESP > DES-CBC Cipher > Algorithm With Explicit IV" [RFC-2405] MUST be supported. Security > issues related to the use of DES are discussed in [DESDIFF], > [DESINT], [DESCRACK]. It is currently viewed as an inherently weak > algorithm, and no longer fulfills its intended role. It is still > required by the existing IPsec RFCs, however. This document > recommends the use of ESP DES-CBC only where interoperability is > required with old implementations supporting DES-CBC. > > The NULL authentication algorithm [RFC-2406] MUST be supported > within > ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- > 2404] MUST be supported. The Use of HMAC-MD5-96 within AH and ESP, > described in [RFC-2403] MUST be supported. An implementer > MUST refer > to Keyed-Hashing for Message Authentication [RFC-2104]. > > 3DES-CBC does not suffer from the issues related to DES-CBC. > 3DES-CBC > and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be supported. AES- > 128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is > expected to > be a widely available, secure algorithm that is required for > interoperability. It is not required by the current IPsec RFCs, > however. > > The "HMAC-SHA-256-96 Algorithm and Its Use With IPsec" [ipsec-ciph- > sha-256] MAY be supported. > > 8.4 Key Management Methods > > Manual keying MUST be supported Manual keying SHOULD be supported (this is changing in MIPv6 it appears)?? > > > > > Loughney (editor) March 3, 2003 > [Page 12] > > > > > > Internet-Draft > August 28, 2003 > > > IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast > traffic. Where key refresh, anti-replay features of AH and ESP, or > on-demand creation of SAs is required, automated keying MUST be > supported. Note that the IPsec WG is working on the successor to > IKE > [SOI]. Key management methods for multicast traffic are also being > worked on by the MSEC WG. > > > 9. Router Functionality > > This section defines general considerations for IPv6 nodes that act > as routers. It is for future study if this document, or a separate > document is needed to fully define IPv6 router requirements. > Currently, this section does not discuss routing protocols. > > 9.1 General > > 9.1.1 IPv6 Router Alert Option - RFC2711 > > The Router Alert Option [RFC-2711] MUST be supported by nodes that > perform packet forwarding at the IP layer (i.e. - the node is a > router). > > 9.1.2 Neighbor Discovery for IPv6 - RFC2461 > > Sending Router Advertisements and processing Router Solicitation > MUST > be supported. > > 10. Network Management > > Network Management, MAY be supported by IPv6 nodes. However, for > IPv6 nodes that are embedded devices, network management may be the > only possibility to control these hosts. > > 10.1 MIBs > > In a general sense, MIBs SHOULD be supported by nodes that support > a > SNMP agent. > > 10.1.1 IP Forwarding Table MIB > > Support for this MIB does not imply that IPv4 or IPv4 specific > portions of this MIB be supported. > > 10.1.2 Management Information Base for the Internet Protocol (IP) > > Support for this MIB does not imply that IPv4 or IPv4 specific > portions of this MIB be supported. > > > > Loughney (editor) March 3, 2003 > [Page 13] > > > > > > Internet-Draft > August 28, 2003 > > > 11. Security Considerations > > This draft does not affect the security of the Internet, but > implementations of IPv6 are expected to support a minimum set of > security features to ensure security on the Internet. "IP Security > Document Roadmap" [RFC-2411] is important for everyone to read. > > The security considerations in RFC2460 describes the following: > > The security features of IPv6 are described in the Security > Architecture for the Internet Protocol [RFC-2401]. > > For example, specific protocol documents and applications may > require > the use of additional security mechanisms. > > The use of ICMPv6 without IPsec can expose the nodes in question to > various kind of attacks including Denial-of-Service, Impersonation, > Man-in-the-Middle, and others. Note that only manually keyed IPsec > can protect some of the ICMPv6 messages that are related to > establishing communications. This is due to chicken-and-egg > problems > on running automated key management protocols on top of > IP. However, > manually keyed IPsec may require a large number of SAs in order to > run on a large network due to the use of many addresses > during ICMPv6 > Neighbor Discovery. > > The use of wide-area multicast communications has an increased risk > from specific security threats, compared with the same threats in > unicast [MC-THREAT]. > > An implementer should also consider the analysis of anycast > [ANYCAST]. > > This document requires an Applicability Statement for implementors. Regards, /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 Tue Mar 18 20:44:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J4iK7f000481; Tue, 18 Mar 2003 20:44:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J4iKhT000480; Tue, 18 Mar 2003 20:44:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J4iG7f000473 for ; Tue, 18 Mar 2003 20:44:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J4iPjO007469 for ; Tue, 18 Mar 2003 20:44:25 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07717 for ; Tue, 18 Mar 2003 21:44:19 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:44:18 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:43:36 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:43:35 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:43:35 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.24]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id UAA14189 for ; Tue, 18 Mar 2003 20:43:22 -0800 (PST) Message-Id: <5.1.0.14.2.20030318233922.03e37318@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 18 Mar 2003 23:39:45 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Fwd: bar-bof on applications and ipv6 site-local Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI -- Margaret >Date: Wed, 19 Mar 2003 04:01:09 +0100 >From: Leif Johansson >User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 >X-Accept-Language: en-us, en >To: discuss@apps.ietf.org, dhc@dcrocker.net, Keith Moore , > Margaret Wasserman >Subject: bar-bof on applications and ipv6 site-local > >Applications-people and ipv6 people who know site-local are invited to >a bar-bof tomorrow night after the plenary (10pm-12am). We meet in >Union 15/16 on the fourth floor of building 3. > >The purpouse of the bar-bof is to start work on/brainstorm around a >position-paper from the apps area on the use of site-local addresses and >address translation in ipv6. Wellcome! > > Cheers Leif -------------------------------------------------------------------- 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 Mar 18 20:59:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J4x27f000721; Tue, 18 Mar 2003 20:59:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J4x2bE000720; Tue, 18 Mar 2003 20:59:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J4wx7f000713 for ; Tue, 18 Mar 2003 20:58:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J4x7cU026583 for ; Tue, 18 Mar 2003 20:59:07 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14294 for ; Tue, 18 Mar 2003 21:59:01 -0700 (MST) From: john.loughney@nokia.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:59:01 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:56:25 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:59:00 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 04:59:00 Z Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2J52au19664 for ; Wed, 19 Mar 2003 07:02:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 06:58:58 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 06:58:58 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 06:58:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] Date: Wed, 19 Mar 2003 06:58:56 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.2 DNS [Re: Nodes Requirements Input] Thread-Index: AcLtl9UuPuTJaOI3ToeS7t3ik+453wAEHFiQAArTWSA= To: , Cc: X-OriginalArrivalTime: 19 Mar 2003 04:58:57.0443 (UTC) FILETIME=[3F869730:01C2EDD4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J4wx7f000714 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > Agreed. But how can a node find an address without MUST DNS. The point > is that a requirement to use is based on the situation. My point last > night. The earlier drafts used different language to try to capture these conditional requirements. The WG did not like the terms (Unconditionally Mandatory, Conditionally Mandatory and Unconditionally Optional), so we dropped them. There seemed to be comments that we should stick to minimum / basic requirements and things which are IPv6 specific. John -------------------------------------------------------------------- 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 Mar 18 21:02:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J52g7f000877; Tue, 18 Mar 2003 21:02:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J52g1X000876; Tue, 18 Mar 2003 21:02:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J52a7f000842 for ; Tue, 18 Mar 2003 21:02:36 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J52ijO011834 for ; Tue, 18 Mar 2003 21:02:44 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18192 for ; Tue, 18 Mar 2003 22:02:38 -0700 (MST) From: john.loughney@nokia.com Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:02:36 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:02:36 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:02:36 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:02:35 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2J56Cu21132 for ; Wed, 19 Mar 2003 07:06:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 07:02:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 07:02:34 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 07:02:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Nodes Requirements Input Date: Wed, 19 Mar 2003 07:02:33 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nodes Requirements Input Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8PgAAq4AgAACwPTEA== To: , X-OriginalArrivalTime: 19 Mar 2003 05:02:33.0742 (UTC) FILETIME=[C07332E0:01C2EDD4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J52a7f000845 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 4.5.1 IP Version 6 Addressing Architecture - RFC2373 > > > > The IPv6 Addressing Architecture [RFC-2373] MUST be supported. > > Currently, this specification is being updated by [ADDRARCHv3]. > > This has changed now. Will update, thanks. > ALso we need to reference Multi6 could affect > this end result. Has Multi6 done anything that we we can reference? John -------------------------------------------------------------------- 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 Mar 18 21:09:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J59s7f001453; Tue, 18 Mar 2003 21:09:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J59rce001452; Tue, 18 Mar 2003 21:09:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J59n7f001436 for ; Tue, 18 Mar 2003 21:09:49 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J59vcU029202 for ; Tue, 18 Mar 2003 21:09:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22367 for ; Tue, 18 Mar 2003 21:09:52 -0800 (PST) From: john.loughney@nokia.com Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:09:51 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:09:51 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:09:51 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:09:50 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2J5DRu23735 for ; Wed, 19 Mar 2003 07:13:27 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 07:09:52 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 07:09:49 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 07:09:48 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 07:09:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Mobility in Nodes Requirements Date: Wed, 19 Mar 2003 07:09:47 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nodes Requirements Input Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8PgAAq4AgAACzB1MA== To: , X-OriginalArrivalTime: 19 Mar 2003 05:09:48.0289 (UTC) FILETIME=[C375CF10:01C2EDD5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J59n7f001438 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > Hosts MAY support mobile node functionality. > > This should be SHOULD. The changing specs are not or can be an issue > but this document is riddled with changing specs. I don't believe that servers, for example, need to implement mobile node functionality. If a node is fixed and will not move, what use is mobile node functionality? > > Hosts SHOULD support route optimization requirements for > > correspondent nodes. Routers do not need to support route > > optimization. > > > > Routers MAY support home agent functionality. > > Routers SHOULD support the HA is correct effort. Otherwise > MIPv6 don't work. Not all routers need to be Home Agents I don't believe that plain, vanilla routers will be affected by home agent functionality. John -------------------------------------------------------------------- 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 Mar 18 21:17:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J5Hn7f001984; Tue, 18 Mar 2003 21:17:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J5HmRL001983; Tue, 18 Mar 2003 21:17:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J5Hj7f001973 for ; Tue, 18 Mar 2003 21:17:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J5HrjO015176 for ; Tue, 18 Mar 2003 21:17:53 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA25913 for ; Tue, 18 Mar 2003 21:17:47 -0800 (PST) From: john.loughney@nokia.com Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:17:47 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:17:47 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:17:46 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 05:17:46 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2J5LNu26881 for ; Wed, 19 Mar 2003 07:21:23 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 07:17:48 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 07:17:43 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 07:17:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: dns discovery for agenda? [Re: chairs and charter] Date: Wed, 19 Mar 2003 07:17:42 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns discovery for agenda? [Re: chairs and charter] Thread-Index: AcLtmZK4BPzZWGSSQWmt07/8MiT4BQAPGA3A To: , , X-OriginalArrivalTime: 19 Mar 2003 05:17:43.0101 (UTC) FILETIME=[DE785ED0:01C2EDD6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J5Hj7f001974 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > > With all due respect, I think this is short sighted. Today you almost > > cannot buy a DSL router for home use that doesn't have an integrated > > DHCP server, among all kinds of other strange stuff. To make a future > > equivalents of such devices also talk DHCPv6 is clearly possible. > > Sure. But that's then still a lot of DHCP code for just DNS discovery > (if DNS discovery is all that is required of the DHCPv6 server, and the > node doesn't need other DHCPv6 options). My major concern about DHCP for DNS discovery will be deployment of DHCPv6 servers. How long will it be before the IETF deploys DHCPv6 at meetings? Already, at a number of IETF meetings, I have had IPv6 addresses, but because of DHCP problems (client and server problems), I have been unable to get IPv4 addresses & DNS server addresses. It breaks down to this, if I want to deploy IPv6 nodes, can I count on DHCPv6 servers being out in the networks? I am not debating or commenting on the DHCPv6 at all, what I am saying is that in the absense of working DHCPv6 servers, I would like a fall-back. If we have statefull address autoconfig & stateful address autoconfig, I think having an additional mechanism for getting DNS server addresses is not a bad thing. At the transport layer, we have UDP, UDP-lite, DCCP, TCP, SCTP ... to transfer packets. Having multiple ways to do something is a reasonable solution. John -------------------------------------------------------------------- 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 Mar 18 21:23:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J5Na7f002322; Tue, 18 Mar 2003 21:23:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J5NaPl002321; Tue, 18 Mar 2003 21:23:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J5NV7f002311 for ; Tue, 18 Mar 2003 21:23:32 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2J5NZP05410; Wed, 19 Mar 2003 06:23:35 +0100 (MET) Date: Wed, 19 Mar 2003 06:19:34 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: dns discovery for agenda? [Re: chairs and charter] To: john.loughney@nokia.com Cc: tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If we have statefull address autoconfig & stateful address autoconfig, I > think having an additional mechanism for getting DNS server addresses is not > a bad thing. At the transport layer, we have UDP, UDP-lite, DCCP, TCP, > SCTP ... to transfer packets. Having multiple ways to do something is a > reasonable solution. Two issues with multiple methods to configure the same thing that hasn't been brought up are: - potential impact on time to discover Since each router advertisement doesn't need to contain all options will a host need to listen for RAs for some time before it decides it to DHCPv6 to find the info? - conflicting information A host might use DHCPv6 for other reasons/other information. What should it do if the RAs and the DHCPv6 reply contains different DNS information? What if different RAs received on the same interface contain different DNS information? 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 Mar 18 22:09:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J69Q7f002775; Tue, 18 Mar 2003 22:09:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J69QJf002774; Tue, 18 Mar 2003 22:09:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J69N7f002767 for ; Tue, 18 Mar 2003 22:09:23 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J69VcU011291 for ; Tue, 18 Mar 2003 22:09:31 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20310 for ; Tue, 18 Mar 2003 22:09:25 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:09:25 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:09:24 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:09:24 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:09:24 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5454B2131; Wed, 19 Mar 2003 01:09:23 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Mar 2003 01:09:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Nodes Requirements Input Date: Wed, 19 Mar 2003 01:09:22 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD2E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nodes Requirements Input Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8PgAAq4AgAACwPTEAACURjw From: "Bound, Jim" To: , X-OriginalArrivalTime: 19 Mar 2003 06:09:23.0123 (UTC) FILETIME=[163A3030:01C2EDDE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J69N7f002768 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Has Multi6 done anything that we we can reference? Nope. Just heads up. It hopefully will be transparent. [p.s.] Him majordomo appears to have dropped me from ipng@sunroof.eng.sun.com could someone at Sun check. I sent mail but it bounced ? 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 Tue Mar 18 22:13:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6DZ7f002905; Tue, 18 Mar 2003 22:13:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J6DZHK002904; Tue, 18 Mar 2003 22:13:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6DV7f002897 for ; Tue, 18 Mar 2003 22:13:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J6DdcU012103 for ; Tue, 18 Mar 2003 22:13:39 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA22877 for ; Tue, 18 Mar 2003 23:13:28 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:12:50 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:12:44 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:12:43 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:12:43 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2F5286B1; Wed, 19 Mar 2003 01:12:43 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Mar 2003 01:12:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Mobility in Nodes Requirements Date: Wed, 19 Mar 2003 01:12:42 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD2F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8PgAAq4AgAACzB1MAACNLvA From: "Bound, Jim" To: , X-OriginalArrivalTime: 19 Mar 2003 06:12:43.0091 (UTC) FILETIME=[8D6AE230:01C2EDDE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J6DW7f002898 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, > Jim, > > > Hosts MAY support mobile node functionality. > > > > This should be SHOULD. The changing specs are not or can > be an issue > > but this document is riddled with changing specs. > > I don't believe that servers, for example, need to implement > mobile node functionality. If a node is fixed and will not > move, what use is mobile node functionality? A server in a helicopter or plane is mobile for a few applications. I understand I am trying to make a point that this exercise needs to be focused on more than the term "node". > > > > Hosts SHOULD support route optimization requirements for > > > correspondent nodes. Routers do not need to support route > > > optimization. > > > > > > Routers MAY support home agent functionality. > > > > Routers SHOULD support the HA is correct effort. Otherwise > > MIPv6 don't work. > > Not all routers need to be Home Agents I don't believe that > plain, vanilla routers will be affected by home agent functionality. Routers that implement MIPv6 SHOULD support HAs. Again context is everything. Thanks /jim > > John > -------------------------------------------------------------------- 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 Mar 18 22:16:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6GR7f003082; Tue, 18 Mar 2003 22:16:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J6GRwe003081; Tue, 18 Mar 2003 22:16:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6GM7f003065 for ; Tue, 18 Mar 2003 22:16:22 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J6GVcU012729 for ; Tue, 18 Mar 2003 22:16:31 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04210 for ; Tue, 18 Mar 2003 22:16:25 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:16:24 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:16:24 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:16:23 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:16:23 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 46AA21237; Wed, 19 Mar 2003 01:16:23 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Mar 2003 01:16:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] Date: Wed, 19 Mar 2003 01:16:22 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD30@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.2 DNS [Re: Nodes Requirements Input] Thread-Index: AcLtl9UuPuTJaOI3ToeS7t3ik+453wAEHFiQAArTWSAAAsecwA== From: "Bound, Jim" To: , Cc: X-OriginalArrivalTime: 19 Mar 2003 06:16:23.0193 (UTC) FILETIME=[109BC890:01C2EDDF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J6GN7f003066 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, > The earlier drafts used different language to try to capture > these conditional requirements. The WG did not like the > terms (Unconditionally Mandatory, > Conditionally Mandatory and Unconditionally Optional), so we > dropped them. There seemed to be comments that we should > stick to minimum / basic requirements and things which are > IPv6 specific. Don't disagree with the WG. I a saying we need multiple node requirements documents. - Node Reqs 3GPP services - Node Database Services - Node Requirements iSCSI/IP Etc Etc. The scope is to narrow currently. Regards, /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 Tue Mar 18 22:24:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6O67f003573; Tue, 18 Mar 2003 22:24:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J6O68c003572; Tue, 18 Mar 2003 22:24:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6O37f003565 for ; Tue, 18 Mar 2003 22:24:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J6OBjO028424 for ; Tue, 18 Mar 2003 22:24:11 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08165 for ; Tue, 18 Mar 2003 22:24:05 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:24:05 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:24:04 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:24:04 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:24:04 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2J6Nw218659; Wed, 19 Mar 2003 08:23:58 +0200 Date: Wed, 19 Mar 2003 08:23:58 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: john.loughney@nokia.com, Subject: RE: Mobility in Nodes Requirements In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD2F@tayexc13.americas.cpqcorp.net> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 19 Mar 2003, Bound, Jim wrote: > > mobile node functionality. If a node is fixed and will not > > move, what use is mobile node functionality? > > A server in a helicopter or plane is mobile for a few applications. I > understand I am trying to make a point that this exercise needs to be > focused on more than the term "node". Such is hardly a minimal or even typical case of IPv6. > > > > Hosts SHOULD support route optimization requirements for > > > > correspondent nodes. Routers do not need to support route > > > > optimization. > > > > > > > > Routers MAY support home agent functionality. > > > > > > Routers SHOULD support the HA is correct effort. Otherwise > > > MIPv6 don't work. > > > > Not all routers need to be Home Agents I don't believe that > > plain, vanilla routers will be affected by home agent functionality. > > Routers that implement MIPv6 SHOULD support HAs. Again context is > everything. There requirement: Routers SHOULD support the requirements set for all IPv6 routers. basically only means the support of new RA intervals and such "trivial" changes -- which enable smoother first-hop-router to MN's-in-foreign-networks scenario. Requiring HA is entirely different issue. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 18 22:25:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6Pv7f003643; Tue, 18 Mar 2003 22:25:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J6PuWL003642; Tue, 18 Mar 2003 22:25:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J6Pr7f003632 for ; Tue, 18 Mar 2003 22:25:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J6Q0cU014884 for ; Tue, 18 Mar 2003 22:26:01 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA28024 for ; Tue, 18 Mar 2003 23:25:53 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:25:51 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:23:15 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:25:50 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 06:25:50 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2J6Phu18668; Wed, 19 Mar 2003 08:25:43 +0200 Date: Wed, 19 Mar 2003 08:25:43 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: john.loughney@nokia.com, , Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD30@tayexc13.americas.cpqcorp.net> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 19 Mar 2003, Bound, Jim wrote: > - Node Reqs 3GPP services > - Node Database Services > - Node Requirements iSCSI/IP > > Etc Etc. > > The scope is to narrow currently. One would think that one could exercise own judgment and listen to the customers (if applicable) when deciding which features to implement on top of the minimal set recommended by node requirements. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 18 23:52:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J7qt7f004351; Tue, 18 Mar 2003 23:52:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2J7qsGp004350; Tue, 18 Mar 2003 23:52:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2J7qp7f004343 for ; Tue, 18 Mar 2003 23:52:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2J7qxjO014617 for ; Tue, 18 Mar 2003 23:52:59 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA00933 for ; Wed, 19 Mar 2003 00:52:50 -0700 (MST) From: jarno.rajahalme@nokia.com Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 07:52:34 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 07:49:59 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 07:52:33 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 07:52:33 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2J7p7M13281 for ; Wed, 19 Mar 2003 09:51:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 09:52:32 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 09:52:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Date: Wed, 19 Mar 2003 09:52:31 +0200 Message-Id: <009CA59D1752DD448E07F8EB2F9117570216EB5F@esebe004.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" Thread-Index: AcLtZ9II5szf39SkQeGgAGwAtvZfqAAg5nZg To: Cc: , , , X-OriginalArrivalTime: 19 Mar 2003 07:52:31.0979 (UTC) FILETIME=[7F12ABB0:01C2EDEC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2J7qq7f004344 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > "unintentionally" is exactly what it means, so there is no problem > > doing this edit. This is related the API-issue above, as the > > interface is required for the applications to be able to specify > > which packets belong to which flow. No raw socket is needed for the > > fiddling, as the interface enabling this is a MUST requirement > > already! > > I'm not sure if I agree with your last sentence. If an application > requests a specific flow label which is already used by another > application at the moment, should the node allow that or > return an error? > > I'd argue for an error, with a possible exception of an app run with > "root" privileges. > What if the "application" is composed of multiple processes? For example audio and data being sourced from two different processes, on two different transport connections, but sharing the same flow (e.g. shared resource reservation). Maybe the process first using a specific Flow Label should be able to specify which other processes could "share" the same labeling for their packets? However, this consideration is clearly out of scope for the flow label spec. Jarno -------------------------------------------------------------------- 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 Mar 19 02:26:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JAQs7f004999; Wed, 19 Mar 2003 02:26:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JAQsTE004998; Wed, 19 Mar 2003 02:26:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JAQp7f004991 for ; Wed, 19 Mar 2003 02:26:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JAQwcU005713 for ; Wed, 19 Mar 2003 02:26:58 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10905 for ; Wed, 19 Mar 2003 03:26:53 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 10:26:51 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 10:26:50 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 10:26:50 Z Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 10:26:50 Z Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail1 with InterScan Messaging Security Suite; Wed, 19 Mar 2003 11:26:30 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 19 Mar 2003 11:26:07 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: dns discovery for agenda? [Re: chairs and charter] Date: Wed, 19 Mar 2003 11:26:07 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns discovery for agenda? [Re: chairs and charter] Thread-Index: AcLt2BX+0yGfP9jQRJ6LK97UpZZ7OAAKHzkg From: "BELOEIL Luc FTRD/DMI/CAE" To: "Erik Nordmark" , Cc: , , X-OriginalArrivalTime: 19 Mar 2003 10:26:07.0895 (UTC) FILETIME=[F42FDA70:01C2EE01] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2JAQp7f004992 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > De : Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] > > > > If we have statefull address autoconfig & stateful address > autoconfig, I > > think having an additional mechanism for getting DNS server > addresses is not > > a bad thing. At the transport layer, we have UDP, > UDP-lite, DCCP, TCP, > > SCTP ... to transfer packets. Having multiple ways to do > something is a > > reasonable solution. > > Two issues with multiple methods to configure the same thing that > hasn't been brought up are: > - potential impact on time to discover > Since each router advertisement doesn't need to contain all > options will a host need to listen for RAs for some time > before it decides it to DHCPv6 to find the info? I agree, that is a generic issue when several mechanisms exist. You could also mentioned "will a host need to wait for DHCPv6 failure before it decides to uses well-known DNS resolver addresses" . > - conflicting information > A host might use DHCPv6 for other reasons/other information. > What should it do if the RAs and the DHCPv6 reply contains > different DNS information? Maybe should we require some architectural constraints to avoid such scenarios? Nevertheless in multihoming scenarios that remains a critical point. > What if different RAs received on the same interface contain > different DNS information? > For that last point, IMHO, DNS information transported in a RA should be associated to the prefix annouced in that RA. If several RA advertise several prefixes with different DNS information it's a matter of policy management on the host. Am I wrong ? Luc -------------------------------------------------------------------- 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 Mar 19 07:47:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JFln7f005935; Wed, 19 Mar 2003 07:47:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JFlnbu005934; Wed, 19 Mar 2003 07:47:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JFlj7f005927 for ; Wed, 19 Mar 2003 07:47:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JFlqcU015428 for ; Wed, 19 Mar 2003 07:47:52 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07738 for ; Wed, 19 Mar 2003 08:47:46 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:47:46 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:45:09 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:47:45 Z Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:47:45 Z Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 584D87B4F1; Wed, 19 Mar 2003 10:47:44 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8FC987B4E1; Wed, 19 Mar 2003 10:47:42 -0500 (EST) Message-Id: <3E78911E.2D4FA6BD@internet2.edu> Date: Wed, 19 Mar 2003 08:47:42 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark Cc: Dave Thaler , Samita Chakrabarti , ipng@sunroof.eng.sun.com, Julien.Laganier@Sun.COM, samita@eng.sun.com Subject: Re: Draft on IPv6 source address selection socket API References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > This has some implication on the number of flags one can invent. > This is the part of the draft that has me concerned. First - I do think the PREFER_LARGEST_SCOPE is needed for a large collection of applications. (With all the noise about site-local in this group, I wonder if a REQUIRE_GLOBAL_SCOPE wouldn't be a good idea...) Second - I wonder how workable it is to have flags for each "preference" type. How likely is it that additional address "types" will come along such that these flags need to be augmented? Will the lag time for adding new flags to working systems make it overly difficult for the applications that need those new flags to be developed? That said: I agree with the direction taken in this draft. It makes the easy things easy. However, it does not make the hard things possible. As an application programmer, I'm not sure this will really give me enough control when/if I need it. What I *think* I would like to see, in addition to this sockopt, is an interface similar to getaddrinfo - but for address pairs, not just for destination addresses. Something that lets me specify both the source and the destination characteristics that I care about - and have it return a linked list of all the src/dst address combinations that are possible given those constraints. Sorted in the same order that the system would have used to choose. This would of course include flags such as described in this draft. (I'm not convinced this much control is really needed yet...) Another possible use for an interface like this is to make it possible to only use "prefer" variants of the flags mentioned in the draft. Then if the application really needs "require" it can examine the address combinations directly. So, I am in support of this draft because I think it goes in the right direction. I just think that an additional draft may be needed down the road a bit... jeff -------------------------------------------------------------------- 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 Mar 19 07:58:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JFw57f006194; Wed, 19 Mar 2003 07:58:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JFw5BG006193; Wed, 19 Mar 2003 07:58:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JFw17f006186 for ; Wed, 19 Mar 2003 07:58:01 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JFw8jO017484 for ; Wed, 19 Mar 2003 07:58:08 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02584 for ; Wed, 19 Mar 2003 07:58:03 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:57:37 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:57:36 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:57:36 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 15:57:35 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2JFvQ522191; Wed, 19 Mar 2003 17:57:26 +0200 Date: Wed, 19 Mar 2003 17:57:26 +0200 (EET) From: Pekka Savola To: jarno.rajahalme@nokia.com cc: brian@hursley.ibm.com, , , Subject: RE: IPv6 w.g. Last Call on "IPv6 Flow Label Specification" In-Reply-To: <009CA59D1752DD448E07F8EB2F9117570216EB5F@esebe004.ntc.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 19 Mar 2003 jarno.rajahalme@nokia.com wrote: > Pekka Savola wrote: > > > "unintentionally" is exactly what it means, so there is no problem > > > doing this edit. This is related the API-issue above, as the > > > interface is required for the applications to be able to specify > > > which packets belong to which flow. No raw socket is needed for the > > > fiddling, as the interface enabling this is a MUST requirement > > > already! > > > > I'm not sure if I agree with your last sentence. If an application > > requests a specific flow label which is already used by another > > application at the moment, should the node allow that or > > return an error? > > > > I'd argue for an error, with a possible exception of an app run with > > "root" privileges. > > > > What if the "application" is composed of multiple processes? For example > audio and data being sourced from two different processes, on two > different transport connections, but sharing the same flow (e.g. shared > resource reservation). Maybe the process first using a specific Flow > Label should be able to specify which other processes could "share" the > same labeling for their packets? Ok, youre correct: that's a valid application of flow labeling. One way to work around this would be having the flow labeling function return some integer number on success, which could be used by other processes as a weak form of "key" to authorize and authenticate their use of the flow label. But that's implementation issue also.. > However, this consideration is clearly out of scope for the flow label > spec. Agreed. (Even though it might be interesting to give some guidance on the implementers on which checks the paragraph discussed would incur in the implementation.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 19 08:39:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGd17f006567; Wed, 19 Mar 2003 08:39:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JGd0sJ006566; Wed, 19 Mar 2003 08:39:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGcv7f006559 for ; Wed, 19 Mar 2003 08:38:57 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JGd4jO029230 for ; Wed, 19 Mar 2003 08:39:04 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03234 for ; Wed, 19 Mar 2003 08:38:59 -0800 (PST) From: john.loughney@nokia.com Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:38:56 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:38:56 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:38:55 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:38:55 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JGbSM22415 for ; Wed, 19 Mar 2003 18:37:28 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 18:38:53 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 18:38:53 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 18:38:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: dns discovery for agenda? [Re: chairs and charter] Date: Wed, 19 Mar 2003 18:38:52 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns discovery for agenda? [Re: chairs and charter] Thread-Index: AcLt17acGAPy1MC+TGSrxHoUEDjxNgAXf9bQ To: Cc: , , X-OriginalArrivalTime: 19 Mar 2003 16:38:52.0752 (UTC) FILETIME=[06AE3500:01C2EE36] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2JGcv7f006560 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > If we have statefull address autoconfig & stateful address > autoconfig, I > > think having an additional mechanism for getting DNS server > addresses is not > > a bad thing. At the transport layer, we have UDP, > UDP-lite, DCCP, TCP, > > SCTP ... to transfer packets. Having multiple ways to do > something is a > > reasonable solution. > > Two issues with multiple methods to configure the same thing that > hasn't been brought up are: > - potential impact on time to discover > Since each router advertisement doesn't need to contain all > options will a host need to listen for RAs for some time > before it decides it to DHCPv6 to find the info? > - conflicting information > A host might use DHCPv6 for other reasons/other information. > What should it do if the RAs and the DHCPv6 reply contains > different DNS information? > What if different RAs received on the same interface contain > different DNS information? I agree that any solution needs to take these 2 issues into account. In summary, the problems seem to be: 1) Ordering of solutions: which to try first and when to try the 2nd. 2) How to resolve conflicting information. Both of these, I think are solvable, but I do agree that the solution needs to propose them. John -------------------------------------------------------------------- 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 Mar 19 08:41:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGfe7f006685; Wed, 19 Mar 2003 08:41:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JGfe9I006684; Wed, 19 Mar 2003 08:41:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGfa7f006671 for ; Wed, 19 Mar 2003 08:41:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JGfhcU002769 for ; Wed, 19 Mar 2003 08:41:43 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20091 for ; Wed, 19 Mar 2003 09:41:37 -0700 (MST) From: john.loughney@nokia.com Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:41:19 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:41:19 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:41:19 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:41:18 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JGdpM23728 for ; Wed, 19 Mar 2003 18:39:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 18:41:17 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 18:41:16 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 18:41:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Mobility in Nodes Requirements Date: Wed, 19 Mar 2003 18:41:15 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8PgAAq4AgAACzB1MAACNLvAABYB2/A= To: , X-OriginalArrivalTime: 19 Mar 2003 16:41:16.0390 (UTC) FILETIME=[5C4BA060:01C2EE36] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2JGfa7f006672 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > I don't believe that servers, for example, need to implement > > mobile node functionality. If a node is fixed and will not > > move, what use is mobile node functionality? > > A server in a helicopter or plane is mobile for a few applications. I > understand I am trying to make a point that this exercise needs to be > focused on more than the term "node". So, perhaps I should have said 'Nodes which change their IP addresses, for example base on Mobile IP, MUST implement mobile node functionality.' Would that kind of text cover your needs. > > > > Hosts SHOULD support route optimization requirements for > > > > correspondent nodes. Routers do not need to support route > > > > optimization. > > > > > > > > Routers MAY support home agent functionality. > > > > > > Routers SHOULD support the HA is correct effort. Otherwise > > > MIPv6 don't work. > > > > Not all routers need to be Home Agents I don't believe that > > plain, vanilla routers will be affected by home agent functionality. > > Routers that implement MIPv6 SHOULD support HAs. Again context is > everything. That text works for me. John -------------------------------------------------------------------- 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 Mar 19 08:48:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGmE7f007164; Wed, 19 Mar 2003 08:48:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JGmDJb007160; Wed, 19 Mar 2003 08:48:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGm97f007144 for ; Wed, 19 Mar 2003 08:48:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JGmGjO002492 for ; Wed, 19 Mar 2003 08:48:16 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24529 for ; Wed, 19 Mar 2003 09:48:11 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:45:42 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP; Wed, 19 Mar 2003 16:45:42 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Wed, 19 Mar 2003 16:45:42 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP; Wed, 19 Mar 2003 16:45:41 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2JGjcX22505; Wed, 19 Mar 2003 18:45:38 +0200 Date: Wed, 19 Mar 2003 18:45:38 +0200 (EET) From: Pekka Savola To: john.loughney@nokia.com cc: Erik.Nordmark@Sun.COM, , , Subject: RE: dns discovery for agenda? [Re: chairs and charter] In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 19 Mar 2003 john.loughney@nokia.com wrote: > I agree that any solution needs to take these 2 issues into > account. In summary, the problems seem to be: > > 1) Ordering of solutions: which to try first and when to try the 2nd. > 2) How to resolve conflicting information. > > Both of these, I think are solvable, but I do agree that the solution > needs to propose them. Perhaps I'm naive but "implementation-specific" would be good enough for me. Consider the case with IPv4. You've manually configured a couple of DNS servers, then run DHCPv4 to get an address and DNS servers. Do you have to specify how to handle the case? The latest wins. Specifying too exactly how to handle these cases may be a rathole, and not essential. If the users are not pleased with the result, they *will* just disable the mechanism producing results they don't like. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 19 08:52:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGqm7f007503; Wed, 19 Mar 2003 08:52:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JGqmVG007502; Wed, 19 Mar 2003 08:52:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGqi7f007492 for ; Wed, 19 Mar 2003 08:52:44 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JGqqjO004009 for ; Wed, 19 Mar 2003 08:52:52 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13261 for ; Wed, 19 Mar 2003 08:52:46 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:52:41 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:52:41 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:52:41 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:52:40 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C342E6A901; Wed, 19 Mar 2003 18:52:35 +0200 (EET) Message-Id: <3E78A020.5000808@kolumbus.fi> Date: Wed, 19 Mar 2003 18:51:44 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: Pekka Savola , john.loughney@nokia.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: 5.2 DNS [Re: Nodes Requirements Input] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 19 Mar 2003, Bound, Jim wrote: >- Node Reqs 3GPP services >- Node Database Services >- Node Requirements iSCSI/IP > >Etc Etc. > >The scope is to narrow currently. Jim, I can see what you would like to do, but I don't agree that this is possible. It is not possible to document the requirements for all potential applications. And I don't want to start arguing about what the three most important applications are, if that's what you were thinking. What we *can* do, however, is to list the "components" IPv6 as a reference for implementers, vendors, and customers. While it may be obvious to some folks what these components are, I believe this is an extremely useful exercise which will also help IPv6 deployment. Also, we in this working group should be able to specify what the core components -- those which are always mandatory no matter what -- are. We are also documenting the optional features*. After a discussion on the mailing list we concluded that the MUST/SHOULD/MAY language is the best choice for this documentation. But by no means should this be taken to mean that an "optional" component is not absolutely necessary in a specific application. Clearly they can be, but I agree with Pekka that some judgment outside the IETF standards needs to be applied as well. Jari *) Actually, only some optional components e.g. on sub-IP are listed. I disagree with this approach, I'd rather have all the optional components. -------------------------------------------------------------------- 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 Mar 19 08:57:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGvn7f007777; Wed, 19 Mar 2003 08:57:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JGvnD4007776; Wed, 19 Mar 2003 08:57:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGvj7f007766 for ; Wed, 19 Mar 2003 08:57:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JGvrcU007905 for ; Wed, 19 Mar 2003 08:57:53 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02605 for ; Wed, 19 Mar 2003 08:57:47 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:57:35 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:54:57 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:57:33 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:57:33 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3261F6A901; Wed, 19 Mar 2003 18:57:31 +0200 (EET) Message-Id: <3E78A147.20002@kolumbus.fi> Date: Wed, 19 Mar 2003 18:56:39 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: "Bound, Jim" , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Mobility in Nodes Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: >>Routers that implement MIPv6 SHOULD support HAs. Again context is >>everything. > > > There requirement: > > Routers SHOULD support the requirements set for all IPv6 routers. > > basically only means the support of new RA intervals and such "trivial" > changes -- which enable smoother first-hop-router to > MN's-in-foreign-networks scenario. Requiring HA is entirely different > issue. This is correct. There are indeed two issues, see Sections 8.3 and 8.4 in the mobile ipv6 specification. As to the requirement to support HAs in all routers... I don't have a strong opinion but I kind of like the MAY. This is because I usually prefer features selling themselves for their benefits, rather than due to them being mandatory in some standard... Jari -------------------------------------------------------------------- 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 Mar 19 08:58:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGw67f007802; Wed, 19 Mar 2003 08:58:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JGw63j007801; Wed, 19 Mar 2003 08:58:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JGw07f007791 for ; Wed, 19 Mar 2003 08:58:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JGw6jO005688 for ; Wed, 19 Mar 2003 08:58:07 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08158 for ; Wed, 19 Mar 2003 09:58:00 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 16:57:29 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Wed, 19 Mar 2003 16:57:27 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Wed, 19 Mar 2003 16:57:27 Z Received: from ms-smtp-01.southeast.rr.com (ms-smtp-01.southeast.rr.com [24.93.67.82]) by relay12.sun.com with ESMTP; Wed, 19 Mar 2003 16:57:26 Z Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ms-smtp-01.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h2JGrFgk019684; Wed, 19 Mar 2003 11:53:23 -0500 (EST) Received: from nc.rr.com ([130.129.130.143]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 19 Mar 2003 11:52:24 -0500 Message-Id: <3E78A059.10504@nc.rr.com> Date: Wed, 19 Mar 2003 11:52:41 -0500 From: Brian Haberman Organization: Me? Organized?? User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark CC: john.loughney@nokia.com, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: dns discovery for agenda? [Re: chairs and charter] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Erik Nordmark wrote: >>If we have statefull address autoconfig & stateful address autoconfig, I >>think having an additional mechanism for getting DNS server addresses is not >>a bad thing. At the transport layer, we have UDP, UDP-lite, DCCP, TCP, >>SCTP ... to transfer packets. Having multiple ways to do something is a >>reasonable solution. > > > Two issues with multiple methods to configure the same thing that > hasn't been brought up are: > - potential impact on time to discover > Since each router advertisement doesn't need to contain all > options will a host need to listen for RAs for some time > before it decides it to DHCPv6 to find the info? > - conflicting information > A host might use DHCPv6 for other reasons/other information. > What should it do if the RAs and the DHCPv6 reply contains > different DNS information? > What if different RAs received on the same interface contain > different DNS information? A few points on your last issue. The NDP spec does state that if two routers detect conflicting info in the RAs that they should log a warning. That approach will help the operator with fixing the conflicting info, but doesn't benefit the nodes that are receiving that info. For them, perhaps what we should do is state that they should honor the RA coming from the router with the lowest IPv6 address. By doing that, operators can assign some level of priority to their RAs. Regards, Brian -------------------------------------------------------------------- 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 Mar 19 09:09:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JH9l7f008473; Wed, 19 Mar 2003 09:09:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JH9lMb008472; Wed, 19 Mar 2003 09:09:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JH9h7f008464 for ; Wed, 19 Mar 2003 09:09:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JH9ojO010069 for ; Wed, 19 Mar 2003 09:09:50 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14438 for ; Wed, 19 Mar 2003 10:09:43 -0700 (MST) From: john.loughney@nokia.com Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:09:19 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:09:18 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:09:17 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:09:17 Z Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JHCru10851 for ; Wed, 19 Mar 2003 19:12:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 19:09:14 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 19:09:14 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 19:09:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: dns discovery for agenda? [Re: chairs and charter] Date: Wed, 19 Mar 2003 19:09:13 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns discovery for agenda? [Re: chairs and charter] Thread-Index: AcLuNvnrkMUrqJKsQaezu9t/7q1ELAAAyKuQ To: Cc: , , , X-OriginalArrivalTime: 19 Mar 2003 17:09:13.0971 (UTC) FILETIME=[44362C30:01C2EE3A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2JH9i7f008465 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > On Wed, 19 Mar 2003 john.loughney@nokia.com wrote: > > I agree that any solution needs to take these 2 issues into > > account. In summary, the problems seem to be: > > > > 1) Ordering of solutions: which to try first and when to > try the 2nd. > > 2) How to resolve conflicting information. > > > > Both of these, I think are solvable, but I do agree that > the solution > > needs to propose them. > > Perhaps I'm naive but "implementation-specific" would be good enough for > me. Well, at least some guidence in the draft would not be a bad thing. > Consider the case with IPv4. You've manually configured a couple of DNS > servers, then run DHCPv4 to get an address and DNS servers. > > Do you have to specify how to handle the case? > > The latest wins. Point taken. > Specifying too exactly how to handle these cases may be a rathole, and not > essential. If the users are not pleased with the result, they *will* just > disable the mechanism producing results they don't like. This is true as well. User preference is a good thing to enable. John -------------------------------------------------------------------- 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 Mar 19 09:31:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JHVI7f008999; Wed, 19 Mar 2003 09:31:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JHVIA6008998; Wed, 19 Mar 2003 09:31:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JHVE7f008991 for ; Wed, 19 Mar 2003 09:31:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JHVMcU020664 for ; Wed, 19 Mar 2003 09:31:22 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26977 for ; Wed, 19 Mar 2003 10:31:16 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:31:14 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:31:14 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:31:14 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:31:13 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C4C056A901; Wed, 19 Mar 2003 19:31:10 +0200 (EET) Message-Id: <3E78A92B.7060007@kolumbus.fi> Date: Wed, 19 Mar 2003 19:30:19 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: Jim.Bound@hp.com, ipng@sunroof.eng.sun.com Subject: Re: Mobility in Nodes Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > Jim, > > >>>I don't believe that servers, for example, need to implement >>>mobile node functionality. If a node is fixed and will not >>>move, what use is mobile node functionality? >> >>A server in a helicopter or plane is mobile for a few applications. I >>understand I am trying to make a point that this exercise needs to be >>focused on more than the term "node". > > > So, perhaps I should have said 'Nodes which change their IP addresses, > for example base on Mobile IP, MUST implement mobile node functionality.' > > Would that kind of text cover your needs. This is a circular definition. The issue is that a node might not know whether its attachment to a network is going to change or not. Those that get these changes, could use mobile IPv6 to deal with it and still keep sessions flowing. Jim may have a point here about the server in a helicopter. But where do we draw the limit? How do we know that 3000 kg IBM mainframe isn't being flown around in a cargo aircraft? Also, the type of the interface on the device may have significance. Or the application; a sensor reporting its findings using a single packet would not need mobility. In conclusion I don't think we can base the mobile node support requirement on the above definition. The options that I see are the following: - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the current text uses MAY). - "Hosts SHOULD/MUST support mobile node functionality ". Here could be e.g. related to the type of the device "on portable devices", or maybe "on devices weighing under 2 kilograms" ;-) We could base it on the type of the interfaces supported, e.g., "on devices that may use wireless interfaces", We could base it on the type of the application, e.g., "on devices that may have applications that require sessions to survive movements". Frankly, I'm not sure it is possible to formulate a good condition for the second option. So I'm inclined to think that its either the current MAY support or possibly SHOULD support. What do people think? >>>>> Hosts SHOULD support route optimization requirements for >>>>> correspondent nodes. Routers do not need to support route >>>>> optimization. >>>>> >>>>> Routers MAY support home agent functionality. >>>> >>>>Routers SHOULD support the HA is correct effort. Otherwise >>>>MIPv6 don't work. >>> >>>Not all routers need to be Home Agents I don't believe that >>>plain, vanilla routers will be affected by home agent functionality. >> >>Routers that implement MIPv6 SHOULD support HAs. Again context is >>everything. > > > That text works for me. Uh... that's also a circular definition. Like Pekka noted already, there are two pieces of router functionality (sections 8.3 and 8.4). The current keywords are SHOULD for the AI option etc and MAY for the HA functionality. We can debate these keywords, but I personally think they are fairly close to the right thing. Jari -------------------------------------------------------------------- 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 Mar 19 09:47:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JHll7f009237; Wed, 19 Mar 2003 09:47:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JHllfp009236; Wed, 19 Mar 2003 09:47:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JHlh7f009229 for ; Wed, 19 Mar 2003 09:47:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JHlpcU027559 for ; Wed, 19 Mar 2003 09:47:51 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09746 for ; Wed, 19 Mar 2003 09:47:45 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:47:38 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Wed, 19 Mar 2003 17:47:38 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Wed, 19 Mar 2003 17:47:37 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay1.sun.com with ESMTP; Wed, 19 Mar 2003 17:47:37 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2JHkavD016599; Wed, 19 Mar 2003 12:46:37 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-635.cisco.com [10.21.98.123]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA01854; Wed, 19 Mar 2003 12:46:34 -0500 (EST) Message-Id: <4.3.2.7.2.20030319123813.03df1f08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Mar 2003 12:43:37 -0500 To: Erik Nordmark From: Ralph Droms Subject: RE: dns discovery for agenda? [Re: chairs and charter] Cc: john.loughney@nokia.com, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: References: <"Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Regarding conflicting DNS information - in theory, it shouldn't matter if there is conflicting information about DNS servers, as the host would receive the same response to a DNS query send to any of the DNS servers. I am DNS-naive and my comment about "in theory" may well be wrong, either in theory or in practice. So, does the choice of DNS server really make a difference or can a host simply choose from the union of all of the lists of DNS servers it receives? - Ralph At 06:19 AM 3/19/2003 +0100, Erik Nordmark wrote: > > If we have statefull address autoconfig & stateful address autoconfig, I > > think having an additional mechanism for getting DNS server addresses > is not > > a bad thing. At the transport layer, we have UDP, UDP-lite, DCCP, TCP, > > SCTP ... to transfer packets. Having multiple ways to do something is a > > reasonable solution. > >Two issues with multiple methods to configure the same thing that >hasn't been brought up are: > - potential impact on time to discover > Since each router advertisement doesn't need to contain all > options will a host need to listen for RAs for some time > before it decides it to DHCPv6 to find the info? > - conflicting information > A host might use DHCPv6 for other reasons/other information. > What should it do if the RAs and the DHCPv6 reply contains > different DNS information? > What if different RAs received on the same interface contain > different DNS information? > > 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 Mar 19 09:51:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JHpW7f009361; Wed, 19 Mar 2003 09:51:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JHpWSY009360; Wed, 19 Mar 2003 09:51:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JHpS7f009350 for ; Wed, 19 Mar 2003 09:51:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JHpZjO026676 for ; Wed, 19 Mar 2003 09:51:35 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12470 for ; Wed, 19 Mar 2003 09:51:30 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 17:51:29 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP; Wed, 19 Mar 2003 17:51:29 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Wed, 19 Mar 2003 17:51:28 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay1.sun.com with ESMTP; Wed, 19 Mar 2003 17:51:27 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2JHqAwY008282; Wed, 19 Mar 2003 19:52:10 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2JHq7gM008279; Wed, 19 Mar 2003 19:52:07 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: dns discovery for agenda? [Re: chairs and charter] From: Mika Liljeberg To: Erik Nordmark Cc: john.loughney@nokia.com, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048096326.28498.37.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 19:52:07 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2003-03-19 at 07:19, Erik Nordmark wrote: > - conflicting information > A host might use DHCPv6 for other reasons/other information. > What should it do if the RAs and the DHCPv6 reply contains > different DNS information? > What if different RAs received on the same interface contain > different DNS information? If they all work, what's the problem? MikaL -------------------------------------------------------------------- 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 Mar 19 10:05:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JI5n7f009782; Wed, 19 Mar 2003 10:05:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JI5nW9009781; Wed, 19 Mar 2003 10:05:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JI5j7f009774 for ; Wed, 19 Mar 2003 10:05:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JI5qcU004890 for ; Wed, 19 Mar 2003 10:05:52 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23468 for ; Wed, 19 Mar 2003 10:05:47 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:05:40 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Wed, 19 Mar 2003 18:03:03 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Wed, 19 Mar 2003 18:05:39 Z Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by relay12.sun.com with ESMTP; Wed, 19 Mar 2003 18:05:38 Z Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:290:27ff:fe50:6bfa]) by tyholt.uninett.no (8.12.8/8.12.6) with ESMTP id h2JI5UgJ008255; Wed, 19 Mar 2003 19:05:30 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.11.6/8.11.2) id h2JI5US24104; Wed, 19 Mar 2003 19:05:30 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 19 Mar 2003 19:05:30 +0100 From: Stig Venaas To: Erik Nordmark Cc: john.loughney@nokia.com, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: dns discovery for agenda? [Re: chairs and charter] Message-Id: <20030319190530.I23981@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Erik.Nordmark@Sun.COM on Wed, Mar 19, 2003 at 06:19:34AM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Mar 19, 2003 at 06:19:34AM +0100, Erik Nordmark wrote: > Two issues with multiple methods to configure the same thing that > hasn't been brought up are: > - potential impact on time to discover > Since each router advertisement doesn't need to contain all > options will a host need to listen for RAs for some time > before it decides it to DHCPv6 to find the info? > - conflicting information > A host might use DHCPv6 for other reasons/other information. > What should it do if the RAs and the DHCPv6 reply contains > different DNS information? > What if different RAs received on the same interface contain > different DNS information? I this problem also might arise for dual-stack host using DHCP. Should it query DHCPv6 and/or DHCP? Should it fall back to one if the other fails? Stig -------------------------------------------------------------------- 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 Mar 19 10:09:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JI9t7f009884; Wed, 19 Mar 2003 10:09:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JI9tGP009883; Wed, 19 Mar 2003 10:09:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JI9p7f009870 for ; Wed, 19 Mar 2003 10:09:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JI9wjO003928 for ; Wed, 19 Mar 2003 10:09:58 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26212 for ; Wed, 19 Mar 2003 11:09:52 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:09:51 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:09:46 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:09:45 Z Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:09:45 Z Received: from user-1121fqd.dsl.mindspring.com ([66.32.191.77] helo=SGOSWAMIPCL) by stork.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18vi0S-0003U5-00 for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 10:09:41 -0800 From: "Subrata Goswami" To: Subject: RE: Mobility in Nodes Requirements Date: Wed, 19 Mar 2003 10:02:21 -0800 Message-Id: <01d601c2ee41$b0866d80$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3E78A92B.7060007@kolumbus.fi> X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b16c600269de330e1fa98f89b252d93a3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are the following motilities. 1. Node mobility (as an aside, if it is a 3000Kg IBM mainframe there should be enough resources on it to support Mobile-IPv6) 2. Subnet/router mobility I guess there was a comment on it from Boeing yesterday at the niim bof. (what about a mobile Cisco GSR ? ) Does MIPv6 say anything about it ? Subrata > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Jari Arkko > Sent: Wednesday, March 19, 2003 9:30 AM > To: john.loughney@nokia.com > Cc: Jim.Bound@hp.com; ipng@sunroof.eng.sun.com > Subject: Re: Mobility in Nodes Requirements > > > john.loughney@nokia.com wrote: > > Jim, > > > > > >>>I don't believe that servers, for example, need to implement mobile > >>>node functionality. If a node is fixed and will not move, what use > >>>is mobile node functionality? > >> > >>A server in a helicopter or plane is mobile for a few > applications. I > >>understand I am trying to make a point that this exercise > needs to be > >>focused on more than the term "node". > > > > > > So, perhaps I should have said 'Nodes which change their IP > addresses, > > for example base on Mobile IP, MUST implement mobile node > > functionality.' > > > > Would that kind of text cover your needs. > > This is a circular definition. The issue is that a node might > not know whether its attachment to a network is going to > change or not. Those that get these changes, could use mobile > IPv6 to deal with it and still keep sessions flowing. > > Jim may have a point here about the server in a helicopter. > But where do we draw the limit? How do we know that 3000 kg > IBM mainframe isn't being flown around in a cargo aircraft? > Also, the type of the interface on the device may have > significance. Or the application; a sensor reporting its > findings using a single packet would not need mobility. > > In conclusion I don't think we can base the mobile node > support requirement on the above definition. The options that > I see are the following: > > - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the > current text uses MAY). > > - "Hosts SHOULD/MUST support mobile node functionality ". > > Here could be e.g. related to the > type of the device "on portable devices", or maybe "on devices > weighing under 2 kilograms" ;-) > > We could base it on the type of the interfaces supported, > e.g., "on devices that may use wireless interfaces", > > We could base it on the type of the application, e.g., "on > devices that may have applications that require sessions to > survive movements". > > Frankly, I'm not sure it is possible to formulate a good > condition for the second option. So I'm inclined to think > that its either the current MAY support or possibly SHOULD > support. What do people think? > > >>>>> Hosts SHOULD support route optimization requirements for > >>>>> correspondent nodes. Routers do not need to support route > >>>>> optimization. > >>>>> > >>>>> Routers MAY support home agent functionality. > >>>> > >>>>Routers SHOULD support the HA is correct effort. Otherwise MIPv6 > >>>>don't work. > >>> > >>>Not all routers need to be Home Agents I don't believe that plain, > >>>vanilla routers will be affected by home agent > functionality. > >> > >>Routers that implement MIPv6 SHOULD support HAs. Again context is > >>everything. > > > > > > That text works for me. > > Uh... that's also a circular definition. Like Pekka noted > already, there are two pieces of router functionality > (sections 8.3 and 8.4). The current keywords are SHOULD for > the AI option etc and MAY for the HA functionality. We can > debate these keywords, but I personally think they are fairly > close to the right thing. > > Jari > > -------------------------------------------------------------------- > 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 Mar 19 10:12:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JICZ7f010027; Wed, 19 Mar 2003 10:12:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JICYip010026; Wed, 19 Mar 2003 10:12:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JICV7f010016 for ; Wed, 19 Mar 2003 10:12:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JICccU007483 for ; Wed, 19 Mar 2003 10:12:38 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28256 for ; Wed, 19 Mar 2003 11:12:32 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:12:28 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:11:46 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:11:46 Z Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:11:44 Z Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:290:27ff:fe50:6bfa]) by tyholt.uninett.no (8.12.8/8.12.6) with ESMTP id h2JIBhgJ008874 for ; Wed, 19 Mar 2003 19:11:43 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.11.6/8.11.2) id h2JIBgr24112 for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 19:11:42 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 19 Mar 2003 19:11:42 +0100 From: Stig Venaas To: ipng@sunroof.eng.sun.com Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] Message-Id: <20030319191142.J23981@sverresborg.uninett.no> References: <20030317060943.GB24236@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030317060943.GB24236@login.ecs.soton.ac.uk>; from tjc@ecs.soton.ac.uk on Mon, Mar 17, 2003 at 06:09:43AM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 17, 2003 at 06:09:43AM +0000, Tim Chown wrote: > OK, well, at present there seems only mild interest at best in this, even > by the original RA method author :) But I'd like to see one more push made > on the concept as it is useful for the stateless scenario (like Pekka, I > visit many IPv6 networks and it is a missing piece - of course in part > because very few people have running DHCPv6, but should they have to deploy > it just for DNS?). A stateless DHCPv6 server (not handing out addresses) might be very light-weight, and it looks like at least some router vendors are about to offer this already. I believe it makes little difference whether the protocol is DHCPv6 or something else, and many hosts and routers will need some form of DHCPv6 support anyway to allow configuration of other parameters. Stig -------------------------------------------------------------------- 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 Mar 19 10:19:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIJP7f010412; Wed, 19 Mar 2003 10:19:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JIJP7Y010411; Wed, 19 Mar 2003 10:19:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIJL7f010401 for ; Wed, 19 Mar 2003 10:19:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JIJSjO007918 for ; Wed, 19 Mar 2003 10:19:28 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21219 for ; Wed, 19 Mar 2003 10:19:23 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:18:57 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:18:51 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:18:51 Z Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:18:51 Z Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2JIIlvD019364; Wed, 19 Mar 2003 13:18:48 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-635.cisco.com [10.21.98.123]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA04857; Wed, 19 Mar 2003 13:18:46 -0500 (EST) Message-Id: <4.3.2.7.2.20030319131554.03e72e68@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Mar 2003 13:18:47 -0500 To: Stig Venaas From: Ralph Droms Subject: Re: why DNS discovery [Re: Revised IPv6 charter and DNS discovery] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20030319191142.J23981@sverresborg.uninett.no> References: <20030317060943.GB24236@login.ecs.soton.ac.uk> <20030317060943.GB24236@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have a stateless DHCPv6 server and client in IOS. They are both pretty lightweight - both to implement and to configure. I'm going to go off this afternoon and try to develop a more quantitative measure of "lightweight". - Rlaph At 07:11 PM 3/19/2003 +0100, Stig Venaas wrote: >On Mon, Mar 17, 2003 at 06:09:43AM +0000, Tim Chown wrote: > > OK, well, at present there seems only mild interest at best in this, even > > by the original RA method author :) But I'd like to see one more push > made > > on the concept as it is useful for the stateless scenario (like Pekka, I > > visit many IPv6 networks and it is a missing piece - of course in part > > because very few people have running DHCPv6, but should they have to deploy > > it just for DNS?). > >A stateless DHCPv6 server (not handing out addresses) might be very >light-weight, and it looks like at least some router vendors are >about to offer this already. I believe it makes little difference >whether the protocol is DHCPv6 or something else, and many hosts and >routers will need some form of DHCPv6 support anyway to allow >configuration of other parameters. > >Stig >-------------------------------------------------------------------- >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 Mar 19 10:26:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIQX7f010925; Wed, 19 Mar 2003 10:26:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JIQXJN010924; Wed, 19 Mar 2003 10:26:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIQS7f010908 for ; Wed, 19 Mar 2003 10:26:28 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2JIQQK14386; Wed, 19 Mar 2003 19:26:26 +0100 (MET) Date: Wed, 19 Mar 2003 19:22:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Draft on IPv6 source address selection socket API To: "Jeff W. Boote" Cc: Erik Nordmark , Dave Thaler , Samita Chakrabarti , ipng@sunroof.eng.sun.com, Julien.Laganier@Sun.COM, samita@eng.sun.com In-Reply-To: "Your message with ID" <3E78911E.2D4FA6BD@internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > First - I do think the PREFER_LARGEST_SCOPE is needed for a large collection > of applications. (With all the noise about site-local in this group, I > wonder if a REQUIRE_GLOBAL_SCOPE wouldn't be a good idea...) Or make PREFER_LARGEST_SCOPE the default? But that isn't the subject of this draft ... > However, it does not make the hard things possible. > > As an application programmer, I'm not sure this will really give me enough > control when/if I need it. What I *think* I would like to see, in addition to > this sockopt, is an interface similar to getaddrinfo - but for address pairs, > not just for destination addresses. Something that lets me specify both the > source and the destination characteristics that I care about - and have it > return a linked list of all the src/dst address combinations that are > possible given those constraints. Sorted in the same order that the system > would have used to choose. This would of course include flags such as > described in this draft. (I'm not convinced this much control is really > needed yet...) I don't quite understand this. You can only express properties about the local addresses (you can't tell from the DNS whether the address you looked up has any particular property). Having said that, being able to do all of address selection in getaddrinfo and have it return a list of src/dst pairs would make certain things simpler. But I think that is orthogonal to adding the preferences and/or requirements on local address types. 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 Wed Mar 19 10:28:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JISN7f010996; Wed, 19 Mar 2003 10:28:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JISNjn010995; Wed, 19 Mar 2003 10:28:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JISJ7f010988 for ; Wed, 19 Mar 2003 10:28:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JISQcU013945 for ; Wed, 19 Mar 2003 10:28:26 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10373 for ; Wed, 19 Mar 2003 11:28:21 -0700 (MST) From: john.loughney@nokia.com Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:28:20 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:28:20 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:28:20 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:28:19 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JIQqM17796 for ; Wed, 19 Mar 2003 20:26:52 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Mar 2003 20:28:17 +0200 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 20:28:17 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Mar 2003 20:28:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: dns discovery for agenda? [Re: chairs and charter] Date: Wed, 19 Mar 2003 20:28:16 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dns discovery for agenda? [Re: chairs and charter] Thread-Index: AcLuQCmRjRT6mKOEQlOknYs7fsNKUQABQooA To: , Cc: , , X-OriginalArrivalTime: 19 Mar 2003 18:28:17.0285 (UTC) FILETIME=[4F727350:01C2EE45] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2JISJ7f010989 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mika, > On Wed, 2003-03-19 at 07:19, Erik Nordmark wrote: > > - conflicting information > > A host might use DHCPv6 for other reasons/other information. > > What should it do if the RAs and the DHCPv6 reply contains > > different DNS information? > > What if different RAs received on the same interface contain > > different DNS information? > > If they all work, what's the problem? I think that the worry is what to do if they all don't work. Therefore, simple rules in what to do in that case is all is needed (I hope). John -------------------------------------------------------------------- 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 Mar 19 10:38:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIc07f011563; Wed, 19 Mar 2003 10:38:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JIc0tk011562; Wed, 19 Mar 2003 10:38:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIbu7f011552 for ; Wed, 19 Mar 2003 10:37:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JIc4cU017660 for ; Wed, 19 Mar 2003 10:38:04 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17682 for ; Wed, 19 Mar 2003 11:37:58 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:37:57 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Wed, 19 Mar 2003 18:35:21 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Wed, 19 Mar 2003 18:37:57 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay12.sun.com with ESMTP; Wed, 19 Mar 2003 18:37:55 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2JIcawY008512; Wed, 19 Mar 2003 20:38:37 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2JIcVOK008509; Wed, 19 Mar 2003 20:38:31 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: dns discovery for agenda? [Re: chairs and charter] From: Mika Liljeberg To: john.loughney@nokia.com Cc: Erik.Nordmark@Sun.COM, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048099110.28501.42.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 20:38:30 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, On Wed, 2003-03-19 at 20:28, john.loughney@nokia.com wrote: > > On Wed, 2003-03-19 at 07:19, Erik Nordmark wrote: > > > - conflicting information > > > A host might use DHCPv6 for other reasons/other information. > > > What should it do if the RAs and the DHCPv6 reply contains > > > different DNS information? > > > What if different RAs received on the same interface contain > > > different DNS information? > > > > If they all work, what's the problem? > > I think that the worry is what to do if they all don't work. Therefore, > simple rules in what to do in that case is all is needed (I hope). That sounds like a configuration error to me. Why advertise dysfuntional DNS servers? It doesn't matter whether there is a single source or multiple sources of DNS addresses. The only way a resolver can choose a working DNS server is to try each server on the list until it finds one. MikaL -------------------------------------------------------------------- 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 Mar 19 10:38:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIcu7f011589; Wed, 19 Mar 2003 10:38:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JIcuwY011588; Wed, 19 Mar 2003 10:38:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JIcq7f011581 for ; Wed, 19 Mar 2003 10:38:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JIcxcU017978 for ; Wed, 19 Mar 2003 10:38:59 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06752 for ; Wed, 19 Mar 2003 11:38:53 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:31:00 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:30:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:30:59 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 18:30:58 Z Received: from localhost (unknown [3ffe:501:100f:13ff::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6B86A15210 for ; Thu, 20 Mar 2003 03:31:13 +0900 (JST) Date: Thu, 20 Mar 2003 03:31:22 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: some opinion about the requirement level of DHCPv6 (for nodereq) User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 56 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2JIcq7f011582 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since I won't be able to join the decision making about the requirement level of DHCPv6, I'd like to present my opinion in an off-site manner. I'll separate the requirement for stateful address autoconfigurataion (the M bit) part and other configuration (the O bit) part, as suggested by Dave. As for stateful autoconfiguration by DHCPv6: If I was just asked to vote either for MAY or for SHOULD, I would vote for MAY, just for the same reason as the one Christian said in the Monday session. However, I can live with SHOULD as well, as long as the requirement clearly states that there may be IPv6 nodes that do not support stateful autoconfiguration and that administrators should take care. What I'm afraid about when we take SHOULD is that the administrators might naively assume it is safe to specify the "M" bit in Router Advertisement (without specifying prefixes that can be used for stateless autoconfiguration). Then many nodes not supporting stateful autoconfiguration might lose global connectivity. >From this point of view, I don't think the following proposal in the ML is a perfect compromise: Stateful Address Autoconfiguration SHOULD be supported, unless all possible use cases for the specific implementation concerned are clearly satisfied by Stateless Address Autoconfiguration. because the phrase "all possible use cases for the specific implementation concerned" is ambiguous. I'd like the text to specify (examples of) "the possible use cases" concretely. Or I'd reverse the logic, like: Stateful Address Autoconfiguration SHOULD be supported, when some use cases for the specific implementation concerned are not satisfied by Stateless Address Autoconfiguration. And/or I'd add an explicit warning to administrators: At the same time, network administrators should take care about the effect of disabling stateless autoconfiguration (see Section 5.3). As for other configuration (e.g. DHCPv6) by DHCPv6: I would vote for SHOULD, with one condition that JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. I have read RFC 2461 and 2462, and I believe I understand the RFCs. p.p.s I'll be offline for 10 hours in 15 minutes. -------------------------------------------------------------------- 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 Mar 19 11:17:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JJH17f012214; Wed, 19 Mar 2003 11:17:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JJH1rs012213; Wed, 19 Mar 2003 11:17:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JJGw7f012206 for ; Wed, 19 Mar 2003 11:16:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JJH5jO028756 for ; Wed, 19 Mar 2003 11:17:05 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11536 for ; Wed, 19 Mar 2003 12:16:59 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 19:16:59 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 19:16:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 19:16:58 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 19:16:58 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA20975 for ; Wed, 19 Mar 2003 19:16:54 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA20345 for ; Wed, 19 Mar 2003 19:16:54 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2JJGsc03830 for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 19:16:54 GMT Date: Wed, 19 Mar 2003 19:16:54 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: 5.2 DNS [Re: Nodes Requirements Input] Message-Id: <20030319191654.GY31092@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD23@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD23@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 18, 2003 at 06:45:25PM -0500, Bound, Jim wrote: > Agreed. But how can a node find an address without MUST DNS. The point > is that a requirement to use is based on the situation. My point last > night. So can we simply add text to the draft to say just that? 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 Wed Mar 19 12:21:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKLk7f012808; Wed, 19 Mar 2003 12:21:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JKLjfn012807; Wed, 19 Mar 2003 12:21:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKLf7f012800 for ; Wed, 19 Mar 2003 12:21:42 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2JKLfK23266; Wed, 19 Mar 2003 21:21:41 +0100 (MET) Date: Wed, 19 Mar 2003 21:17:41 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: dns discovery for agenda? [Re: chairs and charter] To: BELOEIL Luc FTRD/DMI/CAE Cc: Erik Nordmark , john.loughney@nokia.com, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > What if different RAs received on the same interface contain > > different DNS information? > > > > For that last point, IMHO, DNS information transported in a RA should be > associated to the prefix annouced in that RA. If several RA advertise > several prefixes with different DNS information it's a matter of policy > management on the host. Am I wrong ? That doesn't work with the normal way to implement things. DNS information on a node is global - it isn't and can't be associated with an interface in any implementation I know of. Furthermore, associting anything received in an RA with the sender or prefix(es) of that particular RA is not consistent with the model even in neighbor discovery (the prefixes advertised vs. default router selection are separate) let alone shouldn't be visible to higher levels of the stack. While one could revisit these aspects of the IP architecture I'd be leery of making IPv6 different than IPv4 in these respects. 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 Wed Mar 19 12:45:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKjU7f012993; Wed, 19 Mar 2003 12:45:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JKjUxD012992; Wed, 19 Mar 2003 12:45:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKjQ7f012985 for ; Wed, 19 Mar 2003 12:45:27 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2JKjPK24776; Wed, 19 Mar 2003 21:45:25 +0100 (MET) Date: Wed, 19 Mar 2003 21:41:25 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: dns discovery for agenda? [Re: chairs and charter] To: Pekka Savola Cc: john.loughney@nokia.com, Erik.Nordmark@Sun.COM, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Perhaps I'm naive but "implementation-specific" would be good enough for > me. > > Consider the case with IPv4. You've manually configured a couple of DNS > servers, then run DHCPv4 to get an address and DNS servers. > > Do you have to specify how to handle the case? > > The latest wins. The reason this example is naive (well, you asked :-) is when DNSSEC is used the client might have a trust relationship with a particular DNS server (aka recursive resolver) and a secure channel to that resolver. In that case you clearly don't want to replace that manually configured DNS server with the ones the DHCP server tells you to use. But if the client itself does DNSSEC signature validation it would presumably use the best-performing server. 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 Wed Mar 19 12:51:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKpb7f013106; Wed, 19 Mar 2003 12:51:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JKpbrq013105; Wed, 19 Mar 2003 12:51:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKpW7f013095 for ; Wed, 19 Mar 2003 12:51:33 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2JKpWK25165; Wed, 19 Mar 2003 21:51:33 +0100 (MET) Date: Wed, 19 Mar 2003 21:47:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dns discovery for agenda? [Re: chairs and charter] To: Brian Haberman Cc: Erik Nordmark , john.loughney@nokia.com, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: "Your message with ID" <3E78A059.10504@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A few points on your last issue. The NDP spec does state that if > two routers detect conflicting info in the RAs that they should > log a warning. > > That approach will help the operator with fixing the conflicting > info, but doesn't benefit the nodes that are receiving that info. > For them, perhaps what we should do is state that they should > honor the RA coming from the router with the lowest IPv6 address. Yes, this is one way to resolve the conflict. But my point was really trying to be at a higher level: When there are different ways to config the same thing one needs to *think* about conflicts and conflict resolution. The answer might be some scheme for resolving the conflict, or that there isn't such a need for the particular thing that is configured. 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 Wed Mar 19 12:58:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKwk7f013340; Wed, 19 Mar 2003 12:58:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JKwk9I013339; Wed, 19 Mar 2003 12:58:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JKwh7f013332 for ; Wed, 19 Mar 2003 12:58:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JKwojO006198 for ; Wed, 19 Mar 2003 12:58:50 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24137 for ; Wed, 19 Mar 2003 13:58:45 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 20:58:44 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Wed, 19 Mar 2003 20:58:44 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Wed, 19 Mar 2003 20:58:44 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP; Wed, 19 Mar 2003 20:58:43 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2JKwgt24629; Wed, 19 Mar 2003 22:58:42 +0200 Date: Wed, 19 Mar 2003 22:58:41 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: john.loughney@nokia.com, , , Subject: RE: dns discovery for agenda? [Re: chairs and charter] In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 19 Mar 2003, Erik Nordmark wrote: > > Perhaps I'm naive but "implementation-specific" would be good enough for > > me. > > > > Consider the case with IPv4. You've manually configured a couple of DNS > > servers, then run DHCPv4 to get an address and DNS servers. > > > > Do you have to specify how to handle the case? > > > > The latest wins. > > The reason this example is naive (well, you asked :-) > is when DNSSEC is used the client might have a trust relationship with > a particular DNS server (aka recursive resolver) and a secure channel > to that resolver. In that case you clearly don't want to replace > that manually configured DNS server with the ones the DHCP server tells > you to use. As an operator and a user, this case seems trivial: if I know some server(s) are special, I will configure them, and *disallow* any other mechanism from tampering with DNS configuration. Such toggles typically exist in the implementations, and if they don't, I'll switch the implementation. This kind of possibility may require some minor wording ("SHOULD/MUST be configurable") when specifying autoconfiguration mechanisms, but that shouldn't be a problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 19 13:24:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JLOm7f013679; Wed, 19 Mar 2003 13:24:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JLOmS7013678; Wed, 19 Mar 2003 13:24:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JLOi7f013667 for ; Wed, 19 Mar 2003 13:24:44 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2JLOfK27233; Wed, 19 Mar 2003 22:24:42 +0100 (MET) Date: Wed, 19 Mar 2003 22:20:40 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: dns discovery for agenda? [Re: chairs and charter] To: Stig Venaas Cc: Erik Nordmark , john.loughney@nokia.com, tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: "Your message with ID" <20030319190530.I23981@sverresborg.uninett.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I this problem also might arise for dual-stack host using DHCP. > Should it query DHCPv6 and/or DHCP? Should it fall back to one > if the other fails? Yes for the conflicting information question. But I think the issue whether to use DHCPv4 or DHCPv6 are driven by external events. Once it has decided to use both they might present different information for different things. But I think the issue whether DHCPv6 will provide IPv4 addresses for DNS servers is relevant to this issue. I don't recall what the resolution was for that issue. 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 Wed Mar 19 13:58:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JLwT7f013883; Wed, 19 Mar 2003 13:58:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JLwTrq013882; Wed, 19 Mar 2003 13:58:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JLwP7f013874 for ; Wed, 19 Mar 2003 13:58:25 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JLwV9P007946; Wed, 19 Mar 2003 16:58:31 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JLwUaj029069; Wed, 19 Mar 2003 16:58:30 -0500 (EST) Message-Id: <200303192158.h2JLwUaj029069@thunk.east.sun.com> From: Bill Sommerfeld To: john.loughney@nokia.com cc: Jim.Bound@hp.com, ipng@sunroof.eng.sun.com Subject: Re: Mobility in Nodes Requirements In-Reply-To: Your message of "Wed, 19 Mar 2003 07:09:47 +0200." Reply-to: sommerfeld@east.sun.com Date: Wed, 19 Mar 2003 16:58:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't believe that servers, for example, need to implement mobile > node functionality. If a node is fixed and will not move, what use > is mobile node functionality? indeed. and, as another example, my laptop is portable, but is almost always stationary when connected to a network, and as a result does just fine without any mobile node functionality. - 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 Wed Mar 19 14:07:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JM727f013984; Wed, 19 Mar 2003 14:07:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JM72N4013983; Wed, 19 Mar 2003 14:07:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JM6w7f013976 for ; Wed, 19 Mar 2003 14:06:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JM76jO027813 for ; Wed, 19 Mar 2003 14:07:06 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05244 for ; Wed, 19 Mar 2003 15:07:00 -0700 (MST) From: john.loughney@nokia.com Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 22:05:30 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 22:02:13 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 22:02:13 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 22:02:13 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JM0kM16511 for ; Thu, 20 Mar 2003 00:00:46 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 20 Mar 2003 00:02:11 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 00:02:11 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 00:02:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Stateful Address Autoconfiguration & DHCPv6 Date: Thu, 20 Mar 2003 00:02:10 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stateful Address Autoconfiguration & DHCPv6 Thread-Index: AcLuYy5EzJEq1WhHQvGtG9+lu4kj/w== To: X-OriginalArrivalTime: 19 Mar 2003 22:02:11.0543 (UTC) FILETIME=[3142CE70:01C2EE63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2JM6x7f013977 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Reading 2462, it says about the M-bit: ManagedFlag Copied from the M flag field (i.e., the "managed address configuration" flag) of the most recently received Router Advertisement message. The flag indicates whether or not addresses are to be configured using the stateful autoconfiguration mechanism. It starts out in a FALSE state. OtherConfigFlag Copied from the O flag field (i.e., the "other stateful configuration" flag) of the most recently received Router Advertisement message. The flag indicates whether or not information other than addresses is to be obtained using the stateful autoconfiguration mechanism. It starts out in a FALSE state. This makes me believe that by both these being set to FALSE, then Stateful Address Autoconfig is not the default. This, then, seems to imply that Stateful Address Autoconfig support is a SHOULD or MAY. However, further down, it says: If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. and says about the O-bit: If the value of OtherConfigFlag changes from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol, requesting information (excluding addresses if ManagedFlag is set to FALSE). My proposed text is: 4.5.5 Stateful Address Autoconfiguration Stateful Address Autoconfiguration MAY be supported. DHCP [DHCPv6] is the standard stateful address configuration protocol, see section 5.3 for DHCPv6 support. For nodes which do not support Stateful Address Autoconfiguration, an the node may be unable to obtain any IPv6 addresses aside from link-local addresses when it receives a router advertisement with the 'M' flag (Managed address configuration) set and which contains no prefixes advertised for Stateless Address Autoconfiguration (see section 4.5.2). ... If the WG feels that SHOULD is the proper level, I suggest adding something along the lines of: Stateful Address Autoconfiguration SHOULD be supported, unless the possible use cases for the specific implementation concerned are clearly satisfied by Stateless Address Autoconfiguration. ----------------- and ----------- 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) DHCP MUST be supported for nodes that support stateful address autoconfiguration. DHCP SHOULD be supported for nodes which need support for other configuration, such as DNS configuration. Nodes which do not support stateful address autoconfiguration or need support for other configuration, MAY support DHCPv6. DHCP [DHCPv6] is the standard stateful configuration protocol and provides the ability to provide other configuration information to the node. An IPv6 node that does not include an implementation of DHCP will be unable to obtain other configuration information such as the addresses of DNS servers when it is connected to a link over which the node receives a router advertisement in which the 'O' flag ("Other stateful configuration") is set. For those IPv6 Nodes that implement DHCP, those nodes MUST use DHCP upon the receipt of a Router Advertisement with the 'O' flag set (see section 5.5.3 of RFC2462). In addition, in the absence of a router, hosts that implement DHCP MUST attempt to use DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a Router Advertisement can be ignored. Furthermore, in the absence of a router, this type of node is not required to initiate DHCP. -------------------------------------------------------------------- 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 Mar 19 15:30:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JNU47f014754; Wed, 19 Mar 2003 15:30:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2JNU4cg014753; Wed, 19 Mar 2003 15:30:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2JNU07f014746 for ; Wed, 19 Mar 2003 15:30:00 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2JNU8cU005797 for ; Wed, 19 Mar 2003 15:30:08 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07271 for ; Wed, 19 Mar 2003 15:30:02 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 23:30:02 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 23:30:00 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 23:30:00 Z Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 19 Mar 2003 23:30:00 Z Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id DAFDC7B4EE; Wed, 19 Mar 2003 18:29:59 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 118A57B4AF; Wed, 19 Mar 2003 18:29:58 -0500 (EST) Message-Id: <3E78FD75.ED8BC47A@internet2.edu> Date: Wed, 19 Mar 2003 16:29:57 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark Cc: Dave Thaler , Samita Chakrabarti , ipng@sunroof.eng.sun.com, Julien.Laganier@Sun.COM, samita@eng.sun.com Subject: Re: Draft on IPv6 source address selection socket API References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > I don't quite understand this. You can only express properties about > the local addresses (you can't tell from the DNS whether the address you > looked up has any particular property). The destination portion would include the same types of things you can specify about a destination address request to getaddrinfo using "hints". (For example, this would allow you to only accept IPv6 destination addresses, and that definitely has source selection ramifications.) > Having said that, being able to do all of address selection in getaddrinfo > and have it return a list of src/dst pairs would make certain things simpler. > But I think that is orthogonal to adding the preferences and/or requirements > on local address types. Agreed. That is why I suggested this as mostly an additional possibility to provide more control to the application. jeff -------------------------------------------------------------------- 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 Mar 19 16:01:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2K01A7f015128; Wed, 19 Mar 2003 16:01:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2K019ue015127; Wed, 19 Mar 2003 16:01:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2K0167f015120 for ; Wed, 19 Mar 2003 16:01:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2K01DcU016304 for ; Wed, 19 Mar 2003 16:01:13 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03872 for ; Wed, 19 Mar 2003 17:01:08 -0700 (MST) From: john.loughney@nokia.com Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 00:00:42 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 00:00:42 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 00:00:42 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 00:00:41 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2JNxEM00806 for ; Thu, 20 Mar 2003 01:59:14 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Mar 2003 02:00:39 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 02:00:22 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 02:00:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 02:00:19 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLuPViqMfWk8L6QSuSRmwyfPvetkQANkkWQ To: Cc: , X-OriginalArrivalTime: 20 Mar 2003 00:00:21.0946 (UTC) FILETIME=[B37871A0:01C2EE73] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2K0167f015121 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, Do you have any specific text changes compared to the current version? John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 19 March, 2003 19:30 > To: Loughney John (NRC/Helsinki) > Cc: Jim.Bound@hp.com; ipng@sunroof.eng.sun.com > Subject: Re: Mobility in Nodes Requirements > > > john.loughney@nokia.com wrote: > > Jim, > > > > > >>>I don't believe that servers, for example, need to implement > >>>mobile node functionality. If a node is fixed and will not > >>>move, what use is mobile node functionality? > >> > >>A server in a helicopter or plane is mobile for a few > applications. I > >>understand I am trying to make a point that this exercise > needs to be > >>focused on more than the term "node". > > > > > > So, perhaps I should have said 'Nodes which change their IP > addresses, > > for example base on Mobile IP, MUST implement mobile node > functionality.' > > > > Would that kind of text cover your needs. > > This is a circular definition. The issue is that a node might not know > whether its attachment to a network is going to change or not. Those > that get these changes, could use mobile IPv6 to deal with it and > still keep sessions flowing. > > Jim may have a point here about the server in a helicopter. But where > do we draw the limit? How do we know that 3000 kg IBM mainframe > isn't being flown around in a cargo aircraft? Also, the type of > the interface on the device may have significance. Or the application; > a sensor reporting its findings using a single packet would not > need mobility. > > In conclusion I don't think we can base the mobile node support > requirement on the above definition. The options that I see are > the following: > > - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the > current text uses MAY). > > - "Hosts SHOULD/MUST support mobile node functionality ". > > Here could be e.g. related to the > type of the device "on portable devices", or maybe "on devices > weighing under 2 kilograms" ;-) > > We could base it on the type of the interfaces supported, > e.g., "on devices that may use wireless interfaces", > > We could base it on the type of the application, e.g., "on > devices that may have applications that require sessions to > survive movements". > > Frankly, I'm not sure it is possible to formulate a good > condition for the second option. So I'm inclined to think > that its either the current MAY support or possibly SHOULD > support. What do people think? > > >>>>> Hosts SHOULD support route optimization requirements for > >>>>> correspondent nodes. Routers do not need to support route > >>>>> optimization. > >>>>> > >>>>> Routers MAY support home agent functionality. > >>>> > >>>>Routers SHOULD support the HA is correct effort. Otherwise > >>>>MIPv6 don't work. > >>> > >>>Not all routers need to be Home Agents I don't believe that > >>>plain, vanilla routers will be affected by home agent > functionality. > >> > >>Routers that implement MIPv6 SHOULD support HAs. Again context is > >>everything. > > > > > > That text works for me. > > Uh... that's also a circular definition. Like Pekka noted > already, there > are two pieces of router functionality (sections 8.3 and 8.4). The > current keywords are SHOULD for the AI option etc and MAY for the HA > functionality. We can debate these keywords, but I personally think > they are fairly close to the right thing. > > Jari > > -------------------------------------------------------------------- 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 Mar 19 17:11:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2K1Bq7f015742; Wed, 19 Mar 2003 17:11:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2K1BqlB015741; Wed, 19 Mar 2003 17:11:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2K1Bm7f015734 for ; Wed, 19 Mar 2003 17:11:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2K1BujO028603 for ; Wed, 19 Mar 2003 17:11:56 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23139 for ; Wed, 19 Mar 2003 18:11:50 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 01:09:42 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 01:08:29 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 01:08:29 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 01:08:28 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 04D8C6A901; Thu, 20 Mar 2003 03:08:27 +0200 (EET) Message-Id: <3E791458.9040306@kolumbus.fi> Date: Thu, 20 Mar 2003 03:07:36 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: Jim.Bound@hp.com, ipng@sunroof.eng.sun.com Subject: Re: Mobility in Nodes Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > Jari, > > Do you have any specific text changes compared to the current > version? What I was trying to say was that we can debate the right keywords, e.g. HA support MAY => SHOULD but that the current text structure is probably more or less what should have. And I vote for keeping the current keywords, too. Jari -------------------------------------------------------------------- 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 Mar 19 23:33:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2K7Xv7f016741; Wed, 19 Mar 2003 23:33:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2K7Xvh5016740; Wed, 19 Mar 2003 23:33:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2K7Xq7f016733 for ; Wed, 19 Mar 2003 23:33:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2K7XxjO019430 for ; Wed, 19 Mar 2003 23:33:59 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00434 for ; Thu, 20 Mar 2003 00:33:54 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 07:33:53 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 07:33:27 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 07:33:27 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 07:33:26 Z Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0F97F15210 for ; Thu, 20 Mar 2003 16:33:45 +0900 (JST) Date: Thu, 20 Mar 2003 04:19:38 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: some opinion about the requirement level of DHCPv6 (for nodereq) In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (oops, sorry, the message was incomplete) >>>>> On Thu, 20 Mar 2003 03:31:22 +0900, >>>>> JINMEI Tatuya said: > As for other configuration (e.g. DHCPv6) by DHCPv6: > I would vote for SHOULD, with one condition that ... that the other configuration specification is clearly separated from full support of DHCPv6 (to mitigate the load of implementing the full spec). draft-droms-dhcpv6-stateless-guide may help to explore this separation. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 20 07:50:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KFow7f018007; Thu, 20 Mar 2003 07:50:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KFowur018006; Thu, 20 Mar 2003 07:50:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KFot7f017999 for ; Thu, 20 Mar 2003 07:50:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KFp4jO019528 for ; Thu, 20 Mar 2003 07:51:04 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21165 for ; Thu, 20 Mar 2003 07:50:58 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 15:50:43 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 15:50:42 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 15:50:42 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 15:50:41 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2KFoPK32638; Thu, 20 Mar 2003 17:50:25 +0200 Date: Thu, 20 Mar 2003 17:50:24 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: some opinion about the requirement level of DHCPv6 (for nodereq) In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FWIW, I totally agree with Jinmei. I'd like a MAY, but SHOULD worded the-other-way-around, without "unless" is also acceptable. On Thu, 20 Mar 2003, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > Since I won't be able to join the decision making about the > requirement level of DHCPv6, I'd like to present my opinion in an > off-site manner. I'll separate the requirement for stateful address > autoconfigurataion (the M bit) part and other configuration (the O > bit) part, as suggested by Dave. > > As for stateful autoconfiguration by DHCPv6: > > If I was just asked to vote either for MAY or for SHOULD, I would vote > for MAY, just for the same reason as the one Christian said in the > Monday session. However, I can live with SHOULD as well, as long as > the requirement clearly states that there may be IPv6 nodes that do > not support stateful autoconfiguration and that administrators should > take care. > > What I'm afraid about when we take SHOULD is that the administrators > might naively assume it is safe to specify the "M" bit in Router > Advertisement (without specifying prefixes that can be used for > stateless autoconfiguration). Then many nodes not supporting stateful > autoconfiguration might lose global connectivity. > > >From this point of view, I don't think the following proposal in the > ML is a perfect compromise: > > Stateful Address Autoconfiguration SHOULD be supported, unless all > possible use cases for the specific implementation concerned are clearly > satisfied by Stateless Address Autoconfiguration. > > because the phrase "all possible use cases for the specific > implementation concerned" is ambiguous. > > I'd like the text to specify (examples of) "the possible use cases" > concretely. > > Or I'd reverse the logic, like: > > Stateful Address Autoconfiguration SHOULD be supported, when some > use cases for the specific implementation concerned are not > satisfied by Stateless Address Autoconfiguration. > > And/or I'd add an explicit warning to administrators: > > At the same time, network administrators should take care about the > effect of disabling stateless autoconfiguration (see Section 5.3). > > As for other configuration (e.g. DHCPv6) by DHCPv6: > I would vote for SHOULD, with one condition that > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > p.s. I have read RFC 2461 and 2462, and I believe I understand the RFCs. > > p.p.s I'll be offline for 10 hours in 15 minutes. > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 20 08:06:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KG6S7f018258; Thu, 20 Mar 2003 08:06:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KG6RFU018257; Thu, 20 Mar 2003 08:06:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KG6O7f018250 for ; Thu, 20 Mar 2003 08:06:24 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KG6XcU026770 for ; Thu, 20 Mar 2003 08:06:33 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27044 for ; Thu, 20 Mar 2003 08:06:27 -0800 (PST) From: john.loughney@nokia.com Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 16:06:26 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 16:06:26 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 16:06:26 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 16:06:25 Z Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2KG4vM05911 for ; Thu, 20 Mar 2003 18:04:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Mar 2003 18:06:20 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 18:06:22 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 18:06:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: some opinion about the requirement level of DHCPv6 (for nodereq) Date: Thu, 20 Mar 2003 18:06:21 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some opinion about the requirement level of DHCPv6 (for nodereq) Thread-Index: AcLutEg96lRHxxInTZqBBsdUC9XAHwARlWog To: , X-OriginalArrivalTime: 20 Mar 2003 16:06:22.0089 (UTC) FILETIME=[A6686790:01C2EEFA] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jinmei, In the text, I've tried to seperate the requirements for Stateless Address Autoconfig from the use of DHCP for other config info. My opinion is that Stateless Address Autoconfig support is MAY. If a node would need Stateless Address Autoconfig, then DHCPv6 support is a MUST for Stateless Address Autoconfig. If a node needs other config info, then DHCPv6 is a SHOULD, which is independent of Stateless Address Autoconfig. John > -----Original Message----- > From: jinmei@isl.rdc.toshiba.co.jp > [mailto:jinmei@isl.rdc.toshiba.co.jp] > Sent: 19 March, 2003 21:20 > To: ipng@sunroof.eng.sun.com > Subject: Re: some opinion about the requirement level of > DHCPv6 (for nodereq) > > > (oops, sorry, the message was incomplete) > > >>>>> On Thu, 20 Mar 2003 03:31:22 +0900, > >>>>> JINMEI Tatuya said: > > > As for other configuration (e.g. DHCPv6) by DHCPv6: > > I would vote for SHOULD, with one condition that > > ... that the other configuration specification is clearly separated > from full support of DHCPv6 (to mitigate the load of implementing the > full spec). draft-droms-dhcpv6-stateless-guide may help to explore > this separation. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > 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 Thu Mar 20 09:10:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KHAZ7f018792; Thu, 20 Mar 2003 09:10:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KHAZdH018791; Thu, 20 Mar 2003 09:10:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KHAV7f018784 for ; Thu, 20 Mar 2003 09:10:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KHAejO015889 for ; Thu, 20 Mar 2003 09:10:40 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25394 for ; Thu, 20 Mar 2003 09:10:34 -0800 (PST) From: john.loughney@nokia.com Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 17:10:34 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 17:10:33 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 17:10:33 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 17:10:33 Z Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2KH92M21697 for ; Thu, 20 Mar 2003 19:09:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Mar 2003 19:10:25 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 19:10:28 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Mar 2003 19:10:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: some opinion about the requirement level of DHCPv6 (for nodereq) Date: Thu, 20 Mar 2003 19:10:27 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some opinion about the requirement level of DHCPv6 (for nodereq) Thread-Index: AcLutEg96lRHxxInTZqBBsdUC9XAHwARlWogAADTuRA= To: , X-OriginalArrivalTime: 20 Mar 2003 17:10:27.0667 (UTC) FILETIME=[9A8D0A30:01C2EF03] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I, of course, meant stateful below, not stateless. I shouldn't send mail before the caffeine has kicked in. John > -----Original Message----- > From: ext john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 20 March, 2003 18:06 > To: jinmei@isl.rdc.toshiba.co.jp; ipng@sunroof.eng.sun.com > Subject: RE: some opinion about the requirement level of > DHCPv6 (for nodereq) > > > Hi Jinmei, > > In the text, I've tried to seperate the requirements for > Stateless Address Autoconfig > from the use of DHCP for other config info. > > My opinion is that Stateless Address Autoconfig support is > MAY. If a node would need > Stateless Address Autoconfig, then DHCPv6 support is a MUST > for Stateless Address > Autoconfig. > > If a node needs other config info, then DHCPv6 is a SHOULD, > which is independent > of Stateless Address Autoconfig. > > John > > > -----Original Message----- > > From: jinmei@isl.rdc.toshiba.co.jp > > [mailto:jinmei@isl.rdc.toshiba.co.jp] > > Sent: 19 March, 2003 21:20 > > To: ipng@sunroof.eng.sun.com > > Subject: Re: some opinion about the requirement level of > > DHCPv6 (for nodereq) > > > > > > (oops, sorry, the message was incomplete) > > > > >>>>> On Thu, 20 Mar 2003 03:31:22 +0900, > > >>>>> JINMEI Tatuya said: > > > > > As for other configuration (e.g. DHCPv6) by DHCPv6: > > > I would vote for SHOULD, with one condition that > > > > ... that the other configuration specification is clearly separated > > from full support of DHCPv6 (to mitigate the load of > implementing the > > full spec). draft-droms-dhcpv6-stateless-guide may help to explore > > this separation. > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > > Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 20 10:06:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KI6w7f019325; Thu, 20 Mar 2003 10:06:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KI6whJ019324; Thu, 20 Mar 2003 10:06:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KI6t7f019317 for ; Thu, 20 Mar 2003 10:06:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KI73jO005476 for ; Thu, 20 Mar 2003 10:07:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18891 for ; Thu, 20 Mar 2003 11:06:58 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:06:57 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:06:57 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:06:57 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:06:56 Z Content-class: urn:content-classes:message Subject: Clarification about the interoperability requirements for the 'u' bit MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Mar 2003 10:06:51 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504559D@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification about the interoperability requirements for the 'u' bit Thread-Index: AcLvC2kif+mAcoR/ScevHcTDE4Vi1A== From: "Michel Py" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KI6t7f019318 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk After I get back home I will try to do coin some text to clarify this issue. Michel. -------------------------------------------------------------------- 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 Mar 20 10:52:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KIqW7f019702; Thu, 20 Mar 2003 10:52:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KIqWUn019701; Thu, 20 Mar 2003 10:52:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KIqS7f019694 for ; Thu, 20 Mar 2003 10:52:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KIqbjO023756 for ; Thu, 20 Mar 2003 10:52:37 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18435 for ; Thu, 20 Mar 2003 10:52:31 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:52:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:52:30 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:52:30 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 18:52:29 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2KIqPSo055542 for ; Thu, 20 Mar 2003 19:52:26 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2KIqPnc133732 for ; Thu, 20 Mar 2003 19:52:25 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42446 from ; Thu, 20 Mar 2003 19:52:23 +0100 Message-Id: <3E7A0DA6.EFB6FEA@hursley.ibm.com> Date: Thu, 20 Mar 2003 19:51:18 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: some opinion about the requirement level of DHCPv6 (for nodereq) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm afraid it makes no sense in English to use "when", since we are trying to weaken the SHOULD, not to tell implementors how to design their products. I voted for "SHOULD...unless" but I can't support "SHOULD...when". Brian Pekka Savola wrote: > > FWIW, > > I totally agree with Jinmei. I'd like a MAY, but SHOULD worded > the-other-way-around, without "unless" is also acceptable. > > On Thu, 20 Mar 2003, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > Since I won't be able to join the decision making about the > > requirement level of DHCPv6, I'd like to present my opinion in an > > off-site manner. I'll separate the requirement for stateful address > > autoconfigurataion (the M bit) part and other configuration (the O > > bit) part, as suggested by Dave. > > > > As for stateful autoconfiguration by DHCPv6: > > > > If I was just asked to vote either for MAY or for SHOULD, I would vote > > for MAY, just for the same reason as the one Christian said in the > > Monday session. However, I can live with SHOULD as well, as long as > > the requirement clearly states that there may be IPv6 nodes that do > > not support stateful autoconfiguration and that administrators should > > take care. > > > > What I'm afraid about when we take SHOULD is that the administrators > > might naively assume it is safe to specify the "M" bit in Router > > Advertisement (without specifying prefixes that can be used for > > stateless autoconfiguration). Then many nodes not supporting stateful > > autoconfiguration might lose global connectivity. > > > > >From this point of view, I don't think the following proposal in the > > ML is a perfect compromise: > > > > Stateful Address Autoconfiguration SHOULD be supported, unless all > > possible use cases for the specific implementation concerned are clearly > > satisfied by Stateless Address Autoconfiguration. > > > > because the phrase "all possible use cases for the specific > > implementation concerned" is ambiguous. > > > > I'd like the text to specify (examples of) "the possible use cases" > > concretely. > > > > Or I'd reverse the logic, like: > > > > Stateful Address Autoconfiguration SHOULD be supported, when some > > use cases for the specific implementation concerned are not > > satisfied by Stateless Address Autoconfiguration. > > > > And/or I'd add an explicit warning to administrators: > > > > At the same time, network administrators should take care about the > > effect of disabling stateless autoconfiguration (see Section 5.3). > > > > As for other configuration (e.g. DHCPv6) by DHCPv6: > > I would vote for SHOULD, with one condition that > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > > > p.s. I have read RFC 2461 and 2462, and I believe I understand the RFCs. > > > > p.p.s I'll be offline for 10 hours in 15 minutes. > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 20 12:01:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KK1T7f020276; Thu, 20 Mar 2003 12:01:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KK1Tsk020275; Thu, 20 Mar 2003 12:01:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KK1P7f020268 for ; Thu, 20 Mar 2003 12:01:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KK1YcU022134 for ; Thu, 20 Mar 2003 12:01:34 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27921 for ; Thu, 20 Mar 2003 13:01:28 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 20:01:12 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 20:01:11 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 20:01:11 Z Received: from consulintel.es ([213.172.48.142] [213.172.48.142]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 20:01:11 Z Received: from consulintel02 ([130.129.140.228]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Thu, 20 Mar 2003 21:03:36 +0100 Message-Id: <0b3201c2eed0$4f5f5050$e48c8182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 12:02:45 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 130.129.140.228 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-) We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could support this are: 1) Clearly show the advantages of end-to-end and no NAT model. 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the manufacturers to avoid supporting NATs. 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link deprecation ? Regards, Jordi ***************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Register at: http://www.ipv6-es.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 Thu Mar 20 13:03:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KL3l7f020644; Thu, 20 Mar 2003 13:03:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KL3lW2020643; Thu, 20 Mar 2003 13:03:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KL3h7f020636 for ; Thu, 20 Mar 2003 13:03:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KL3pjO011455 for ; Thu, 20 Mar 2003 13:03:52 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20417 for ; Thu, 20 Mar 2003 14:03:46 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:03:45 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:03:45 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:03:45 Z Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:03:45 Z Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail1 with InterScan Messaging Security Suite; Thu, 20 Mar 2003 22:03:14 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Mar 2003 22:02:51 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 21:53:58 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcLvG8N/fVKkbiFBTuG6k6knniaEmwABRxrQ From: "BINET David FTRD/DMI/CAE" To: "JORDI PALET MARTINEZ" , X-OriginalArrivalTime: 20 Mar 2003 21:02:51.0632 (UTC) FILETIME=[11CD3F00:01C2EF24] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KL3i7f020637 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, > After the today's decision with site local, is clear to me > that we don't want to have NAT happening again ) I think it was clear before SL discussion. > > We know that the people will do it anyway, but we must do an > effort to avoid is as much as possible, and some ideas that could > support this are: > > 1) Clearly show the advantages of end-to-end and no NAT model. > 2) Have the specs indicating that an IPv6 node (host/router, > whatever) MUST NOT support NAT or equivalent mechanisms. Any > interoperability/conformance test must fail if you fail to > agree with this specification. This should be a clear sign for the > manufacturers to avoid supporting NATs. > 3) Indicate that if someone wants to keep using NAT, should > do it with IPv4. The good question is: why customers use NATs ? Maybe, it is because of the lack of public addresses and surely there are some other reasons ! So I am not convinced by the interdiction of NATs in IPv6 node requirements (is it possible ?) but I would prefer a constructive solution that provides right solutions for customer needs. End to end secure communications is a nice goal but is it possible today to propose such service for any customer or in any environment ? > > I'm not sure if the rest agree and what is the correct > document to say this, may be as part of the changes for the local-link > deprecation ? > > Regards, > Jordi David > > > ***************************** > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Register at: > http://www.ipv6-es.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 20 13:33:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KLXY7f020996; Thu, 20 Mar 2003 13:33:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KLXYhj020995; Thu, 20 Mar 2003 13:33:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KLXU7f020988 for ; Thu, 20 Mar 2003 13:33:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KLXdcU027918 for ; Thu, 20 Mar 2003 13:33:39 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19078 for ; Thu, 20 Mar 2003 13:33:33 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:33:32 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:33:32 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:33:31 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:33:31 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 45F7089D1; Thu, 20 Mar 2003 22:33:24 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 6A3798998; Thu, 20 Mar 2003 22:33:19 +0100 (CET) From: "Jeroen Massar" To: "'BINET David FTRD/DMI/CAE'" , "'JORDI PALET MARTINEZ'" , Subject: RE: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 22:34:15 +0100 Organization: Unfix Message-Id: <000701c2ef28$75ff2160$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KLXV7f020989 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk BINET David FTRD/DMI/CAE wrote: > > After the today's decision with site local, is clear to me > > that we don't want to have NAT happening again ) > I think it was clear before SL discussion. > > > > We know that the people will do it anyway, but we must do an > > effort to avoid is as much as possible, and some ideas that could > > support this are: > > > > 1) Clearly show the advantages of end-to-end and no NAT model. > > 2) Have the specs indicating that an IPv6 node (host/router, > > whatever) MUST NOT support NAT or equivalent mechanisms. Any > > interoperability/conformance test must fail if you fail to > > agree with this specification. This should be a clear sign for the > > manufacturers to avoid supporting NATs. > > 3) Indicate that if someone wants to keep using NAT, should > > do it with IPv4. > > The good question is: why customers use NATs ? > Maybe, it is because of the lack of public addresses and > surely there are some other reasons ! > So I am not convinced by the interdiction of NATs in IPv6 > node requirements (is it possible ?) but I would prefer > a constructive solution that provides > right solutions for customer needs. End to end secure > communications is a nice goal but is it possible today to > propose such service for any customer or in any environment ? In IPv6 every enduser should have enough IP's simply because of the simple rule: - when in doubt that the user might ever have 1+ subnets give them a /48. otherwise you might give them a /64. But that quickly boils down to passing a /48 to everybody because that's much easier to administrate in the books. Though using 1 /48 for passing out single /64's from that is nice solution too ofcourse. Bigger customers can ofcourse get bigger blocks or extra /48's. And when the LIR runs out it should get a bigger one from the RIR etc. Nevertheless customers should never have any need whatsoever for NAT. If there once is a need for it IPv6 'failed' as it didn't get up to the primary need for IPv6: More addressspace so that everything can be e2e. Taking this into consideration NAT's can be banned from IPv6 and what Jordi stated above is IMHO completely correct. As for people who think that a NAT is a firewall: it isn't. (Though usually functions of firewalls are also built into NAT's) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 20 13:41:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KLfB7f021239; Thu, 20 Mar 2003 13:41:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KLfBVF021238; Thu, 20 Mar 2003 13:41:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KLf77f021231 for ; Thu, 20 Mar 2003 13:41:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KLfGjO024679 for ; Thu, 20 Mar 2003 13:41:16 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20899 for ; Thu, 20 Mar 2003 14:41:10 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:41:10 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:38:30 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:41:09 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:41:08 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2KLf5OI111086 for ; Thu, 20 Mar 2003 22:41:05 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2KLf5nc256690 for ; Thu, 20 Mar 2003 22:41:05 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45732 from ; Thu, 20 Mar 2003 22:41:03 +0100 Message-Id: <3E7A352F.4F26D7FB@hursley.ibm.com> Date: Thu, 20 Mar 2003 22:39:59 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 References: <0b3201c2eed0$4f5f5050$e48c8182@consulintel.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd vote for a MUST NOT in node requirements, if we can find a suitable phrasing. It may well be violated by vendors, but it makes the situation unambiguous. Brian JORDI PALET MARTINEZ wrote: > > After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-) > > We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could > support this are: > > 1) Clearly show the advantages of end-to-end and no NAT model. > 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any > interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the > manufacturers to avoid supporting NATs. > 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. > > I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link > deprecation ? > > Regards, > Jordi > > ***************************** > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Register at: > http://www.ipv6-es.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 > -------------------------------------------------------------------- -------------------------------------------------------------------- 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 Mar 20 13:44:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KLit7f021412; Thu, 20 Mar 2003 13:44:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KLite0021411; Thu, 20 Mar 2003 13:44:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KLiq7f021404 for ; Thu, 20 Mar 2003 13:44:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KLj0cU002191 for ; Thu, 20 Mar 2003 13:45:00 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18919 for ; Thu, 20 Mar 2003 14:44:54 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:44:53 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:44:31 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:44:31 Z Received: from consulintel.es ([213.172.48.142] [213.172.48.142]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 21:44:31 Z Received: from consulintel02 ([130.129.79.218]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Thu, 20 Mar 2003 22:46:50 +0100 Message-Id: <0c1001c2eede$bb97e6c0$e48c8182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 13:46:26 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 130.129.79.218 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, agree, but the constructive solution is IPv6 itself. We need to show it (probably out of the scope of the IETF). We need also to understand other reasons why NAT is there and provide solutions, if not available with today's IPv6. We know that NAT is used because disconnected networks become connected, because false security impression, and because the lack of enough addressing space. What other reasons are to use NAT ? Jordi ----- Original Message ----- From: "BINET David FTRD/DMI/CAE" To: "JORDI PALET MARTINEZ" ; Sent: Thursday, March 20, 2003 9:53 PM Subject: RE: avoiding NAT with IPv6 > Hello, > > > After the today's decision with site local, is clear to me > > that we don't want to have NAT happening again ) > I think it was clear before SL discussion. > > > > We know that the people will do it anyway, but we must do an > > effort to avoid is as much as possible, and some ideas that could > > support this are: > > > > 1) Clearly show the advantages of end-to-end and no NAT model. > > 2) Have the specs indicating that an IPv6 node (host/router, > > whatever) MUST NOT support NAT or equivalent mechanisms. Any > > interoperability/conformance test must fail if you fail to > > agree with this specification. This should be a clear sign for the > > manufacturers to avoid supporting NATs. > > 3) Indicate that if someone wants to keep using NAT, should > > do it with IPv4. > The good question is: why customers use NATs ? > Maybe, it is because of the lack of public addresses and surely there > are some other reasons ! > So I am not convinced by the interdiction of NATs in IPv6 node requirements > (is it possible ?) but I would prefer a constructive solution that provides > right solutions for customer needs. End to end secure communications is a > nice goal but is it possible today to propose such service for any customer or > in any environment ? > > > > I'm not sure if the rest agree and what is the correct > > document to say this, may be as part of the changes for the local-link > > deprecation ? > > > > Regards, > > Jordi > David > > > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > 12-14 May 2003 - Register at: > > http://www.ipv6-es.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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > ***************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Register at: http://www.ipv6-es.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 Thu Mar 20 14:25:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMPD7f021979; Thu, 20 Mar 2003 14:25:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMPDI4021978; Thu, 20 Mar 2003 14:25:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMPA7f021971 for ; Thu, 20 Mar 2003 14:25:10 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMPIcU016070 for ; Thu, 20 Mar 2003 14:25:18 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25472 for ; Thu, 20 Mar 2003 14:25:12 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:25:11 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:25:11 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:25:11 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:25:10 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA26209; Thu, 20 Mar 2003 22:25:06 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA16205; Thu, 20 Mar 2003 22:25:06 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2KMP6o19759; Thu, 20 Mar 2003 22:25:06 GMT Date: Thu, 20 Mar 2003 22:25:06 +0000 From: Tim Chown To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 Message-Id: <20030320222506.GI19356@login.ecs.soton.ac.uk> Mail-Followup-To: Brian E Carpenter , ipng@sunroof.eng.sun.com References: <0b3201c2eed0$4f5f5050$e48c8182@consulintel.es> <3E7A352F.4F26D7FB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E7A352F.4F26D7FB@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, If the phrasing focuses on rewriting of the source address, then we do not preclude use of fec0::/10 for disconnected networks, router zeroconf, or elsewhere. We just say "IPv6 nodes MUST NOT rewrite IPv6 source addresses when processing packets". As Pekka said, fec0::/10 need not be blackholed - it can be treated as a global address instead with no special processing. Clearly we do not want NAT, but we cannot ban it as such or stop vendors providing what customers want. However, we also still have to be realistic in enabling ad-hoc or intermittently connected networks, so I like the idea of discouraging the functionality in products (even without site-locals, people will pick address blocks to use, and we may see leakage of "hijacked" addresses and all manner of problems as a result...) Still, I guess this morning's vote will focus minds :) Tim On Thu, Mar 20, 2003 at 10:39:59PM +0100, Brian E Carpenter wrote: > I'd vote for a MUST NOT in node requirements, if we can find a suitable > phrasing. It may well be violated by vendors, but it makes the situation > unambiguous. > > Brian > > JORDI PALET MARTINEZ wrote: > > > > After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-) > > > > We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could > > support this are: > > > > 1) Clearly show the advantages of end-to-end and no NAT model. > > 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any > > interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the > > manufacturers to avoid supporting NATs. > > 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. > > > > I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link > > deprecation ? > > > > Regards, > > Jordi > > > > ***************************** > > Madrid 2003 Global IPv6 Summit > > 12-14 May 2003 - Register at: > > http://www.ipv6-es.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 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > 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 Thu Mar 20 14:45:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMjO7f022416; Thu, 20 Mar 2003 14:45:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMjOjW022415; Thu, 20 Mar 2003 14:45:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMjL7f022408 for ; Thu, 20 Mar 2003 14:45:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMjTcU022776 for ; Thu, 20 Mar 2003 14:45:29 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11308 for ; Thu, 20 Mar 2003 15:45:24 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:44:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:42:12 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:44:51 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:44:51 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5C94D231A; Thu, 20 Mar 2003 17:44:51 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 17:44:51 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 17:44:50 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD7C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLt4CMs9bNV8q/jT7ur75L7nvxfJwBUdtCQ From: "Bound, Jim" To: "Pekka Savola" Cc: , X-OriginalArrivalTime: 20 Mar 2003 22:44:51.0244 (UTC) FILETIME=[515FEEC0:01C2EF32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KMjL7f022409 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > > A server in a helicopter or plane is mobile for a few > applications. I > > understand I am trying to make a point that this exercise > needs to be > > focused on more than the term "node". > > Such is hardly a minimal or even typical case of IPv6. So you only want to work on the typical case in the IETF? It appears you do not care about the non typical? If you watch TV though this looks pretty typical to me :--) /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 Thu Mar 20 14:46:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMkp7f022436; Thu, 20 Mar 2003 14:46:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMkoPO022435; Thu, 20 Mar 2003 14:46:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMkl7f022428 for ; Thu, 20 Mar 2003 14:46:47 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMktjO017054 for ; Thu, 20 Mar 2003 14:46:56 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09762 for ; Thu, 20 Mar 2003 14:46:50 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:46:49 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:46:49 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:46:49 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:46:48 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 611E46398; Thu, 20 Mar 2003 17:46:48 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 17:46:48 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 17:46:43 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD7D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLtZnZU689sp1imTmSjlRA5hWKs0QAFy8PgAAq4AgAACzB1MAACNLvAABYB2/AAPxHi8A== From: "Bound, Jim" To: , X-OriginalArrivalTime: 20 Mar 2003 22:46:48.0289 (UTC) FILETIME=[97239510:01C2EF32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KMkl7f022429 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, That would work. But I am already working on my IESG appeal and case for stateful so go for it. I will state my case to the IESG once it is done with Last Call as appeal when/if it is done. Thanks /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, March 19, 2003 11:41 AM > To: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: RE: Mobility in Nodes Requirements > > > Jim, > > > > I don't believe that servers, for example, need to implement > > > mobile node functionality. If a node is fixed and will not > > > move, what use is mobile node functionality? > > > > A server in a helicopter or plane is mobile for a few > applications. I > > understand I am trying to make a point that this exercise > needs to be > > focused on more than the term "node". > > So, perhaps I should have said 'Nodes which change their IP > addresses, for example base on Mobile IP, MUST implement > mobile node functionality.' > > Would that kind of text cover your needs. > > > > > > Hosts SHOULD support route optimization requirements for > > > > > correspondent nodes. Routers do not need to support route > > > > > optimization. > > > > > > > > > > Routers MAY support home agent functionality. > > > > > > > > Routers SHOULD support the HA is correct effort. > Otherwise MIPv6 > > > > don't work. > > > > > > Not all routers need to be Home Agents I don't believe that > > > plain, vanilla routers will be affected by home agent > functionality. > > > > Routers that implement MIPv6 SHOULD support HAs. Again context is > > everything. > > That text works for me. > > John > -------------------------------------------------------------------- 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 Mar 20 14:47:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMle7f022456; Thu, 20 Mar 2003 14:47:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMldjB022455; Thu, 20 Mar 2003 14:47:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMla7f022448 for ; Thu, 20 Mar 2003 14:47:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMlicU023581 for ; Thu, 20 Mar 2003 14:47:44 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26297 for ; Thu, 20 Mar 2003 14:47:39 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:47:38 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:47:37 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:47:37 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:47:36 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5BB8C63A1; Thu, 20 Mar 2003 17:47:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 17:47:36 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 17:47:35 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD7E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLuOLJNL0JDBEy8TE6bZCXXicP+lQA+e7iw From: "Bound, Jim" To: "Jari Arkko" , "Pekka Savola" Cc: , X-OriginalArrivalTime: 20 Mar 2003 22:47:36.0181 (UTC) FILETIME=[B3AF5250:01C2EF32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KMla7f022449 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, THen go fix 2119. I am basing my comments on that RFC. Thanks /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, March 19, 2003 11:57 AM > To: Pekka Savola > Cc: Bound, Jim; john.loughney@nokia.com; ipng@sunroof.eng.sun.com > Subject: Re: Mobility in Nodes Requirements > > > > Pekka Savola wrote: > > >>Routers that implement MIPv6 SHOULD support HAs. Again context is > >>everything. > > > > > > There requirement: > > > > Routers SHOULD support the requirements set for all IPv6 routers. > > > > basically only means the support of new RA intervals and such > > "trivial" > > changes -- which enable smoother first-hop-router to > > MN's-in-foreign-networks scenario. Requiring HA is > entirely different > > issue. > > This is correct. There are indeed two issues, see Sections > 8.3 and 8.4 in the mobile ipv6 specification. > > As to the requirement to support HAs in all routers... I > don't have a strong opinion but I kind of like the MAY. This > is because I usually prefer features selling themselves for > their benefits, rather than due to them being mandatory in > some standard... > > Jari > > -------------------------------------------------------------------- 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 Mar 20 14:48:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMm57f022479; Thu, 20 Mar 2003 14:48:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMm59u022478; Thu, 20 Mar 2003 14:48:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMlx7f022461 for ; Thu, 20 Mar 2003 14:47:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMm7cU023708 for ; Thu, 20 Mar 2003 14:48:07 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15733 for ; Thu, 20 Mar 2003 15:48:01 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:48:00 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:48:00 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:48:00 Z Received: from consulintel.es ([213.172.48.142] [213.172.48.142]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:48:00 Z Received: from consulintel02 ([130.129.79.218]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Thu, 20 Mar 2003 23:50:26 +0100 Message-Id: <0d4f01c2eee7$9dff5e50$e48c8182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <0b3201c2eed0$4f5f5050$e48c8182@consulintel.es> <3E7A352F.4F26D7FB@hursley.ibm.com> <20030320222506.GI19356@login.ecs.soton.ac.uk> Subject: Re: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 14:50:00 +0100 Organization: Consulintel 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 130.129.79.218 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, I don't agree: Yes we can STOP vendors. If they don't match the document, they will not be complaint with the RFC, and thus pass interoperability/conformance test. This is the same way we ask them to implement things. This time we ask them NOT to implement it. Jordi ----- Original Message ----- From: "Tim Chown" To: "Brian E Carpenter" Cc: Sent: Thursday, March 20, 2003 11:25 PM Subject: Re: avoiding NAT with IPv6 > Brian, > > If the phrasing focuses on rewriting of the source address, then we do > not preclude use of fec0::/10 for disconnected networks, router zeroconf, > or elsewhere. We just say "IPv6 nodes MUST NOT rewrite IPv6 source > addresses when processing packets". > > As Pekka said, fec0::/10 need not be blackholed - it can be treated as > a global address instead with no special processing. > > Clearly we do not want NAT, but we cannot ban it as such or stop vendors > providing what customers want. > > However, we also still have to be realistic in enabling ad-hoc or > intermittently connected networks, so I like the idea of discouraging the > functionality in products (even without site-locals, people will pick > address blocks to use, and we may see leakage of "hijacked" addresses and > all manner of problems as a result...) > > Still, I guess this morning's vote will focus minds :) > > Tim > > On Thu, Mar 20, 2003 at 10:39:59PM +0100, Brian E Carpenter wrote: > > I'd vote for a MUST NOT in node requirements, if we can find a suitable > > phrasing. It may well be violated by vendors, but it makes the situation > > unambiguous. > > > > Brian > > > > JORDI PALET MARTINEZ wrote: > > > > > > After the today's decision with site local, is clear to me that we don't want to have NAT happening again ;-) > > > > > > We know that the people will do it anyway, but we must do an effort to avoid is as much as possible, and some ideas that could > > > support this are: > > > > > > 1) Clearly show the advantages of end-to-end and no NAT model. > > > 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any > > > interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the > > > manufacturers to avoid supporting NATs. > > > 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. > > > > > > I'm not sure if the rest agree and what is the correct document to say this, may be as part of the changes for the local-link > > > deprecation ? > > > > > > Regards, > > > Jordi > > > > > > ***************************** > > > Madrid 2003 Global IPv6 Summit > > > 12-14 May 2003 - Register at: > > > http://www.ipv6-es.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 > > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > ***************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Register at: http://www.ipv6-es.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 Thu Mar 20 14:50:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMnx7f022541; Thu, 20 Mar 2003 14:50:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMnxnF022540; Thu, 20 Mar 2003 14:49:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMns7f022530 for ; Thu, 20 Mar 2003 14:49:54 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMo3jO018096 for ; Thu, 20 Mar 2003 14:50:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11706 for ; Thu, 20 Mar 2003 14:49:57 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:49:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:49:55 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:49:55 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:49:55 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id DD1F0575; Thu, 20 Mar 2003 17:49:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 17:49:54 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 17:49:54 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD7F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLuPVf36mQ8LddrT9GZOSvFeK+SZQA9WphQ From: "Bound, Jim" To: "Jari Arkko" , Cc: X-OriginalArrivalTime: 20 Mar 2003 22:49:54.0727 (UTC) FILETIME=[0643C370:01C2EF33] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KMnt7f022531 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is pretty simple folks. Just focus the title of the document and not make it general node requirements. The general node reqs are in the RFCs for IPv6. They do not need to be re-written. This document started because the 3GPP vendors did not want to do all the musts in the RFCs. Fine so lets just make this a 3GPP document which it was in the first place. /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, March 19, 2003 12:30 PM > To: john.loughney@nokia.com > Cc: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: Re: Mobility in Nodes Requirements > > > john.loughney@nokia.com wrote: > > Jim, > > > > > >>>I don't believe that servers, for example, need to implement > >>>mobile node functionality. If a node is fixed and will not > >>>move, what use is mobile node functionality? > >> > >>A server in a helicopter or plane is mobile for a few > applications. I > >>understand I am trying to make a point that this exercise > needs to be > >>focused on more than the term "node". > > > > > > So, perhaps I should have said 'Nodes which change their IP > addresses, > > for example base on Mobile IP, MUST implement mobile node > > functionality.' > > > > Would that kind of text cover your needs. > > This is a circular definition. The issue is that a node might > not know whether its attachment to a network is going to > change or not. Those that get these changes, could use mobile > IPv6 to deal with it and still keep sessions flowing. > > Jim may have a point here about the server in a helicopter. > But where do we draw the limit? How do we know that 3000 kg > IBM mainframe isn't being flown around in a cargo aircraft? > Also, the type of the interface on the device may have > significance. Or the application; a sensor reporting its > findings using a single packet would not need mobility. > > In conclusion I don't think we can base the mobile node > support requirement on the above definition. The options that > I see are the following: > > - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the > current text uses MAY). > > - "Hosts SHOULD/MUST support mobile node functionality ". > > Here could be e.g. related to the > type of the device "on portable devices", or maybe "on devices > weighing under 2 kilograms" ;-) > > We could base it on the type of the interfaces supported, > e.g., "on devices that may use wireless interfaces", > > We could base it on the type of the application, e.g., "on > devices that may have applications that require sessions to > survive movements". > > Frankly, I'm not sure it is possible to formulate a good > condition for the second option. So I'm inclined to think > that its either the current MAY support or possibly SHOULD > support. What do people think? > > >>>>> Hosts SHOULD support route optimization requirements for > >>>>> correspondent nodes. Routers do not need to support route > >>>>> optimization. > >>>>> > >>>>> Routers MAY support home agent functionality. > >>>> > >>>>Routers SHOULD support the HA is correct effort. Otherwise MIPv6 > >>>>don't work. > >>> > >>>Not all routers need to be Home Agents I don't believe that > >>>plain, vanilla routers will be affected by home agent > functionality. > >> > >>Routers that implement MIPv6 SHOULD support HAs. Again context is > >>everything. > > > > > > That text works for me. > > Uh... that's also a circular definition. Like Pekka noted > already, there are two pieces of router functionality > (sections 8.3 and 8.4). The current keywords are SHOULD for > the AI option etc and MAY for the HA functionality. We can > debate these keywords, but I personally think they are fairly > close to the right thing. > > Jari > > -------------------------------------------------------------------- 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 Mar 20 14:51:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMpk7f022705; Thu, 20 Mar 2003 14:51:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMpjOA022704; Thu, 20 Mar 2003 14:51:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMpf7f022691 for ; Thu, 20 Mar 2003 14:51:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMpocU024974 for ; Thu, 20 Mar 2003 14:51:50 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18048 for ; Thu, 20 Mar 2003 15:51:44 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:51:44 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:51:43 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:51:43 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:51:43 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 743FA5E5; Thu, 20 Mar 2003 17:51:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 17:51:42 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] Date: Thu, 20 Mar 2003 17:51:41 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD80@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.2 DNS [Re: Nodes Requirements Input] Thread-Index: AcLt4GJU+m4QvuOqTwGsI5qXpSYa9ABUs1Ow From: "Bound, Jim" To: "Pekka Savola" Cc: , , X-OriginalArrivalTime: 20 Mar 2003 22:51:42.0273 (UTC) FILETIME=[465DFB10:01C2EF33] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KMpg7f022693 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, And one could do all this by using the current specs. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, March 19, 2003 1:26 AM > To: Bound, Jim > Cc: john.loughney@nokia.com; brian@hursley.ibm.com; > ipng@sunroof.eng.sun.com > Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] > > > On Wed, 19 Mar 2003, Bound, Jim wrote: > > - Node Reqs 3GPP services > > - Node Database Services > > - Node Requirements iSCSI/IP > > > > Etc Etc. > > > > The scope is to narrow currently. > > One would think that one could exercise own judgment and > listen to the > customers (if applicable) when deciding which features to > implement on top > of the minimal set recommended by node requirements. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- 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 Mar 20 14:55:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMtj7f023219; Thu, 20 Mar 2003 14:55:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMtiXh023218; Thu, 20 Mar 2003 14:55:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMtd7f023203 for ; Thu, 20 Mar 2003 14:55:39 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMtlcU026469 for ; Thu, 20 Mar 2003 14:55:47 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01491 for ; Thu, 20 Mar 2003 14:55:42 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:55:41 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:55:41 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:55:41 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:55:40 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2KMtaK03604; Fri, 21 Mar 2003 00:55:36 +0200 Date: Fri, 21 Mar 2003 00:55:35 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: Jari Arkko , , Subject: RE: Mobility in Nodes Requirements In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD7F@tayexc13.americas.cpqcorp.net> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Mar 2003, Bound, Jim wrote: > This document started because the 3GPP vendors did not want to do all > the musts in the RFCs. Fine so lets just make this a 3GPP document > which it was in the first place. I thought the issue was more about *WHICH* RFC's to implement, no which MUSTs (or whatever) to ignore in those RFC's they intend to implement. The same applies in node reqs, I think. > > -----Original Message----- > > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > > Sent: Wednesday, March 19, 2003 12:30 PM > > To: john.loughney@nokia.com > > Cc: Bound, Jim; ipng@sunroof.eng.sun.com > > Subject: Re: Mobility in Nodes Requirements > > > > > > john.loughney@nokia.com wrote: > > > Jim, > > > > > > > > >>>I don't believe that servers, for example, need to implement > > >>>mobile node functionality. If a node is fixed and will not > > >>>move, what use is mobile node functionality? > > >> > > >>A server in a helicopter or plane is mobile for a few > > applications. I > > >>understand I am trying to make a point that this exercise > > needs to be > > >>focused on more than the term "node". > > > > > > > > > So, perhaps I should have said 'Nodes which change their IP > > addresses, > > > for example base on Mobile IP, MUST implement mobile node > > > functionality.' > > > > > > Would that kind of text cover your needs. > > > > This is a circular definition. The issue is that a node might > > not know whether its attachment to a network is going to > > change or not. Those that get these changes, could use mobile > > IPv6 to deal with it and still keep sessions flowing. > > > > Jim may have a point here about the server in a helicopter. > > But where do we draw the limit? How do we know that 3000 kg > > IBM mainframe isn't being flown around in a cargo aircraft? > > Also, the type of the interface on the device may have > > significance. Or the application; a sensor reporting its > > findings using a single packet would not need mobility. > > > > In conclusion I don't think we can base the mobile node > > support requirement on the above definition. The options that > > I see are the following: > > > > - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the > > current text uses MAY). > > > > - "Hosts SHOULD/MUST support mobile node functionality ". > > > > Here could be e.g. related to the > > type of the device "on portable devices", or maybe "on devices > > weighing under 2 kilograms" ;-) > > > > We could base it on the type of the interfaces supported, > > e.g., "on devices that may use wireless interfaces", > > > > We could base it on the type of the application, e.g., "on > > devices that may have applications that require sessions to > > survive movements". > > > > Frankly, I'm not sure it is possible to formulate a good > > condition for the second option. So I'm inclined to think > > that its either the current MAY support or possibly SHOULD > > support. What do people think? > > > > >>>>> Hosts SHOULD support route optimization requirements for > > >>>>> correspondent nodes. Routers do not need to support route > > >>>>> optimization. > > >>>>> > > >>>>> Routers MAY support home agent functionality. > > >>>> > > >>>>Routers SHOULD support the HA is correct effort. Otherwise MIPv6 > > >>>>don't work. > > >>> > > >>>Not all routers need to be Home Agents I don't believe that > > >>>plain, vanilla routers will be affected by home agent > > functionality. > > >> > > >>Routers that implement MIPv6 SHOULD support HAs. Again context is > > >>everything. > > > > > > > > > That text works for me. > > > > Uh... that's also a circular definition. Like Pekka noted > > already, there are two pieces of router functionality > > (sections 8.3 and 8.4). The current keywords are SHOULD for > > the AI option etc and MAY for the HA functionality. We can > > debate these keywords, but I personally think they are fairly > > close to the right thing. > > > > Jari > > > > > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 20 14:56:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMuJ7f023381; Thu, 20 Mar 2003 14:56:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KMuIEJ023374; Thu, 20 Mar 2003 14:56:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KMu47f023291 for ; Thu, 20 Mar 2003 14:56:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KMuCcU026640 for ; Thu, 20 Mar 2003 14:56:12 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05719 for ; Thu, 20 Mar 2003 15:56:06 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:54:04 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:50:27 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:53:06 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 22:53:05 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2KMqtd03577; Fri, 21 Mar 2003 00:52:55 +0200 Date: Fri, 21 Mar 2003 00:52:54 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: john.loughney@nokia.com, Subject: RE: Mobility in Nodes Requirements In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD7C@tayexc13.americas.cpqcorp.net> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Mar 2003, Bound, Jim wrote: > > > A server in a helicopter or plane is mobile for a few > > applications. I > > > understand I am trying to make a point that this exercise > > needs to be > > > focused on more than the term "node". > > > > Such is hardly a minimal or even typical case of IPv6. > > So you only want to work on the typical case in the IETF? > > It appears you do not care about the non typical? No, but we certainly *must* consider what's typical when setting *requirements* for *all* nodes. Non-typical cases are fine -- and will be used, that's great, the more IPv6 the better -- but I don't see why such should set what the mainline does. I can easily envision server on a helicopter. That's a case, of course. But something that must be taken into consideration when implementing the helicopter and the server. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 20 15:17:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNHJ7f024571; Thu, 20 Mar 2003 15:17:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KNHJfC024570; Thu, 20 Mar 2003 15:17:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNHE7f024563 for ; Thu, 20 Mar 2003 15:17:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KNHNjO028759 for ; Thu, 20 Mar 2003 15:17:23 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29970 for ; Thu, 20 Mar 2003 15:17:17 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:17:17 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:17:16 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:17:16 Z Received: from roll.mentat.com (roll.mentat.com [192.88.122.129]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:17:15 Z Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2KNHH519050; Thu, 20 Mar 2003 15:17:18 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2KNHHA10495; Thu, 20 Mar 2003 15:17:17 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id PAA17556; Thu, 20 Mar 2003 15:22:56 -0800 (PST) Date: Thu, 20 Mar 2003 15:22:56 -0800 (PST) From: Tim Hartrick Message-Id: <200303202322.PAA17556@feller.mentat.com> To: jari.arkko@kolumbus.fi, Jim.Bound@hp.com Subject: RE: Mobility in Nodes Requirements Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > This is pretty simple folks. Just focus the title of the document and > not make it general node requirements. The general node reqs are in the > RFCs for IPv6. They do not need to be re-written. > > This document started because the 3GPP vendors did not want to do all > the musts in the RFCs. Fine so lets just make this a 3GPP document > which it was in the first place. > In general, I agree with Jim here. I have never seen the need for an IPv6 node requirements specification. The need for the IPv4 host requirements document was in large part driven by the large number of ambiguities and bugs in the original IPv4 RFCs. The IETF has a complete process for addressing ambiguities and bugs in RFCs (they are revised and obsoleted) so the need for a IPv6 node requirements document is pretty questionable. If the other RFCs are correct a node requirements document for IPv6 should be nothing but a list of current RFCs. We already have lists of RFCs. I am not denigrating the effort that has gone into this document. John and others have clearly worked hard on the text and the consensus building but it seems to me that this document and the debate about it are talking around the issue that was the genesis of this effort. This effort began as a way for the 3GPP crowd to strip out features of IPv6 that they didn't want to implement. Some of the reasons for not wanting to implement features were legitimate and some weren't. For example, if there are characteristics of 3GPP LINKs that make certain features of ND unnecessary then that should be documented in an IPv6 over 3GPP specification but if the intent is to say that "3GPP nodes" are things that don't have much storage and don't have much memory so we need to throw out pieces of ND to make it fit then that is a different matter entirely because it is taking a snap shot in time of what a constitutes a "3GPP node" and may well have serious interoperability consequences for the "3GPP node" that one day grows an 802.11b interface. I doubt that this late arriving opinion will matter much but that is my two cents on the issue. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- 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 Mar 20 15:28:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNSS7f024915; Thu, 20 Mar 2003 15:28:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KNSSaM024914; Thu, 20 Mar 2003 15:28:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNSP7f024907 for ; Thu, 20 Mar 2003 15:28:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KNSXcU009713 for ; Thu, 20 Mar 2003 15:28:33 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12930 for ; Thu, 20 Mar 2003 16:28:27 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:28:26 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:28:25 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:28:25 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:28:25 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2KNSH503868; Fri, 21 Mar 2003 01:28:17 +0200 Date: Fri, 21 Mar 2003 01:28:17 +0200 (EET) From: Pekka Savola To: Tim Hartrick cc: jari.arkko@kolumbus.fi, , Subject: RE: Mobility in Nodes Requirements In-Reply-To: <200303202322.PAA17556@feller.mentat.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Mar 2003, Tim Hartrick wrote: > In general, I agree with Jim here. I have never seen the need for an > IPv6 node requirements specification. The need for the IPv4 host requirements > document was in large part driven by the large number of ambiguities and > bugs in the original IPv4 RFCs. [...] I agree, at least to a degree: I believe the optimal category should be BCP or Informational. PS (as is currently in the charter) is also fine, though I see little which would require this -- and in fact might give a wrong picture of the nature of the memo. But this is a discussion we probably have had many times -- too bad I just remember the outcome and justifications (well, one: IPv4 NodeReqs was PS for reasons given by Tim). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 20 15:37:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNbY7f025199; Thu, 20 Mar 2003 15:37:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KNbY63025198; Thu, 20 Mar 2003 15:37:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNbU7f025188 for ; Thu, 20 Mar 2003 15:37:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KNbdjO005644 for ; Thu, 20 Mar 2003 15:37:39 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02644 for ; Thu, 20 Mar 2003 16:37:33 -0700 (MST) From: john.loughney@nokia.com Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:37:18 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:37:11 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:37:11 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:37:11 Z Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2KNeou22181 for ; Fri, 21 Mar 2003 01:40:50 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Mar 2003 01:37:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 01:37:08 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 01:37:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Mobility in Nodes Requirements Date: Fri, 21 Mar 2003 01:37:07 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLvOTSXIcfwsGyCRpmc5mV0IGC/WwAADmHQ To: Cc: X-OriginalArrivalTime: 20 Mar 2003 23:37:07.0980 (UTC) FILETIME=[9F03DCC0:01C2EF39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2KNbV7f025189 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > I agree, at least to a degree: I believe the optimal category should be > BCP or Informational. PS (as is currently in the charter) is also fine, > though I see little which would require this -- and in fact might give a > wrong picture of the nature of the memo. My opinion is that the document should be a BCP. Hopefully, the chairs could confirm or deny this. > But this is a discussion we probably have had many times -- too bad I just > remember the outcome and justifications (well, one: IPv4 NodeReqs was PS > for reasons given by Tim). IPv4 Node Req predated PS, etc. notations, I think. John -------------------------------------------------------------------- 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 Mar 20 15:40:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNeY7f025254; Thu, 20 Mar 2003 15:40:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KNeYfr025253; Thu, 20 Mar 2003 15:40:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNeV7f025246 for ; Thu, 20 Mar 2003 15:40:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KNedcU014161 for ; Thu, 20 Mar 2003 15:40:39 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21298 for ; Thu, 20 Mar 2003 16:40:33 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:39:26 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP; Thu, 20 Mar 2003 23:39:25 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP; Thu, 20 Mar 2003 23:39:25 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay2.sun.com with ESMTP; Thu, 20 Mar 2003 23:39:25 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2KNdCM31226; Fri, 21 Mar 2003 00:39:12 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2KNdCof061873; Fri, 21 Mar 2003 00:39:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303202339.h2KNdCof061873@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Mon, 24 Feb 2003 17:17:15 PST. <200302250117.h1P1H2im410272@jurassic.eng.sun.com> Date: Fri, 21 Mar 2003 00:39:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: A draft has been submitted to address source address selection at the per-socket (and per apps) basis. Currently it discusses preferences of source address selection by the application for privacy addresses, mobileipv6 addresses and Cryptographically generated addresses. Thus the application can reverse the sense of default source address selection by using the proposed APIs. => I have a major concern about the style of the API: it is at the socket level ([gs]etsockopt()) when it should be in the context of applications: - nobody wants to modify every applications in order to use the API (an unfortunately many applications can want to toggle one of the address selection knobs) - at the opposite a global knob is not flexible again. What I propose is to put the policy in the context of applications (Unix user structure, environment, etc, even monitors have this kind of things) so one can tune the address selection before launching applications. When the context can be managed from applications (the usual case), this makes [gs]etsockopt() no more necessary. And global flags can be replaced by default values... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 20 15:54:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNsJ7f025996; Thu, 20 Mar 2003 15:54:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2KNsI40025995; Thu, 20 Mar 2003 15:54:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2KNsF7f025988 for ; Thu, 20 Mar 2003 15:54:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2KNsNcU018991 for ; Thu, 20 Mar 2003 15:54:24 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05568 for ; Thu, 20 Mar 2003 16:54:06 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:52:48 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:52:47 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:52:47 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 20 Mar 2003 23:52:47 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2KNqYM31901; Fri, 21 Mar 2003 00:52:34 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2KNqZof061924; Fri, 21 Mar 2003 00:52:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303202352.h2KNqZof061924@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Mon, 24 Feb 2003 17:17:15 PST. <200302250117.h1P1H2im410272@jurassic.eng.sun.com> Date: Fri, 21 Mar 2003 00:52:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some details: ..., CGA (cryptographically generated addresses) and non-CGA addresses etc.. => you should note that CGAs are covered by some IPRs. It is recommended that the application does a getsockopt() prior => this comes only from the uncommon style (one flag from Home, another one from Care-of, etc). The following flags are added for the ai_flags in addrinfo data structure defined in Basic IPv6 Socket API Extension [2]. AI_PREFER_SRC_HOME AI_PREFER_SRC_COA AI_PREFER_SRC_TMP AI_PREFER_SRC_PUBLIC AI_PREFER_SRC_CGA AI_PREFER_SRC_NONCGA => why _SRC_ ? 5. IPv4-Mapped IPv6 Addresses IPv4-Mapped IPv6 addresses are not supported for setting preference on home, care-of-address, CGA, non-CGA, public or privacy auto- configured addresses as source addresses. Because they are all pure IPv6 addresses. => this is not true for home/care-of and this section is not useful. 6. Security Considerations It is also recommended that the applications set IPV6_V6ONLY IP level socket option to permit the nodes to not process IPv4 packets as IPv4 Mapped addresses. => I disagree about the implicit argument that IPv4 Mapped IPv6 addresses are unsafe. And BTW this has nothing to do in this document. 7. Open Issues - Are there more flags we should define at this point in time? For instance, PREFER_LARGEST_SCOPE? => all "matter of taste" rules of address selection which cannot be controlled through the policy table should be covered here. - Is there a need for REQUIRE flags in addition to or instead of the PREFER flags? => yes, in some cases it is very important. Note that in general it isn't possible to verify that a requirement can be satisfied until sendto() or connect() (when the destination address is known) thus this would result in late errors being reported to the application. => this is not really true because an application can use a connect() to verify the selected source but as I am against any changes in application I agree with the conclusion. - Is there a need for "validation" functions to go with these preferences such as functions that check whether an address is a temporary address? => it should be useful for some applications to have access to status of addresses. Thanks Francis.Dupont@enst-bretagne.fr draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 7] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 8. References Normative references: [1] Richard Draves, "Default Address Selection for IPv6", draft-ietf-ipv6-default-addr-select-09.txt, August 6, 2002. [2] R.E. Gilligan, S. Thomson, J. Bound, J. McCann, W. R. Stevens, "Basic Socket Interface Extensions for IPv6", draft-ietf-ipngwg-rfc2553bis-10.txt, December, 2002. Informative references: [3] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6" draft-ietf-mobileip-ipv6-20.txt, January, 2003. [4] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6), Specification", RFC 2460, Dec. 1998. [5] Stevens, W. R, Thomas, M., Nordmark, E., Jinmei, T., "Advanced Sockets API for IPv6", draft-ietf-ipngwg-rfc2292bis-07.txt April 19, 2002. [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [7] Montenegro, G. and C. Castelluccia, "Statistically Unique and Cryptographically Verifiable (SUCV) Identifiers and Addresses.", NDSS 2002, February 2002. [8] Castelluccia, C. and G. Montenegro, "Securing Group Management in IPv6 with Cryptographically Generated Addresses", draft-irtf-gsec-sgmv6-01 (work in progress), July 2002. 9. Acknowledgements The authors like to thank members of mobile-ip and ipv6 working groups for useful discussion on this topic. Richard Draves and Dave Thaler suggested that getaddrinfo also needs to be considered along with the new socket option. Gabriel Montenegro suggested that CGAs may also be considered in this document. Thanks to Alain Durand, Renee Danson, Alper Yegin and Francis Dupont for useful discussions. draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 8] INTERNET-DRAFT IPv6 Socket API for source address selection Feb., 2003 10. Authors' Addresses Erik Nordmark Sun Microsystems Laboratories, Europe 180 Avenue de l'Europe 38334 Saint Ismier, France Email: Erik.Nordmark@sun.com Samita Chakrabarti Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054, USA Email: samita.chakrabarti@Sun.com Julien Laganier Sun Microsystems Laboratories, Europe 180 Avenue de l'Europe 38334 Saint Ismier, France Email: Julien.Laganier@Sun.COM draft-chakrabarti-ipv6-addrselect-api-00.txt [Page 9] --Clutter_of_Cats_249_000-- -------------------------------------------------------------------- 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 Mar 20 16:21:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L0L07f026418; Thu, 20 Mar 2003 16:21:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L0L0fA026417; Thu, 20 Mar 2003 16:21:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L0Ku7f026410 for ; Thu, 20 Mar 2003 16:20:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L0L5jO019158 for ; Thu, 20 Mar 2003 16:21:05 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12473 for ; Thu, 20 Mar 2003 17:20:59 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 00:20:59 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 00:20:59 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 00:20:59 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 00:20:58 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2L0KoM32550; Fri, 21 Mar 2003 01:20:50 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2L0Kpof062003; Fri, 21 Mar 2003 01:20:51 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303210020.h2L0Kpof062003@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Julien Laganier cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, samita@eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Fri, 21 Mar 2003 01:03:31 +0100. <200303210103.31022.julien.laganier@sun.com> Date: Fri, 21 Mar 2003 01:20:51 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Le Vendredi 21 Mars 2003 00:39, Francis Dupont a écrit : => you should avoid French in this list (:-). It is expected that most applications should work fine without tuning the => this is exactly the assumption I strongly disagree with. source address selection algorithm. If an application cannot work fine with system-wide defaults, then the develloper should be aware of that, and may choose to use this API. I guess that what your point here is that end users may want to tune the behavior of many applications they use without modyfing them. I believe it is a different problem. => this is the problem we have to solve. Do you want to recompile your mozilla in order to add a new parameter for home/care-of choice, for instance to use the best option when you know where is a Web server... Moreover, defining this policy in the environment may not be sufficiently fine-grained for a lot of applications: A single application may want to send packets using both its CoA and HoA as a source address, or both its TMP and Public, etc. => the policy in the environment has the same capability than your proposal when the environment can be changed from applications. And this is the usual case. An example of that is an application that first use a TMP address, and after authentication switch to a PUB address. Same thing with CGA that allows ownership-authentication => BTW I strongly disagree about this idea that CGAs provide any kind of authentication. but is not always supported by both peers, so you can revert to a non-CGA if authentication fails. However, your proposition of having an environment "thing" that tweak the source address selection for applications that does not use this API sounds good to me, but I believe this is not the scope of this document. => so write another more useful one? Seriously I believe that all the tuning stuff, including your knobs, the policy table and other things like the DNS search list (a global one makes no sense as quoted today), should be in an environment "thing" with a standard way to manage it. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 20 17:06:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L1607f026805; Thu, 20 Mar 2003 17:06:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L15x6F026804; Thu, 20 Mar 2003 17:05:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L15u7f026797 for ; Thu, 20 Mar 2003 17:05:56 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L165jO002795 for ; Thu, 20 Mar 2003 17:06:05 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22539 for ; Thu, 20 Mar 2003 17:05:59 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:05:58 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:05:55 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:05:55 Z Received: from TheWorld.com ([199.172.62.103] [199.172.62.103]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:05:55 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8/8.12.8) with ESMTP id h2L15lS1023847; Thu, 20 Mar 2003 20:05:47 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id UAA5969365; Thu, 20 Mar 2003 20:05:34 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Thu, 20 Mar 2003 20:05:33 -0500 From: Quality Quorum To: JORDI PALET MARTINEZ cc: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 In-Reply-To: <0b3201c2eed0$4f5f5050$e48c8182@consulintel.es> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Mar 2003, JORDI PALET MARTINEZ wrote: > After the today's decision with site local, is clear to me that we don't > want to have NAT happening again ;-) > > We know that the people will do it anyway, but we must do an effort > to avoid is as much as possible, and some ideas that could > support this are: IETF is big and strong, market[lace is much bigger and much stronger, in all previous collisions with market IETF did not fare well. Note - I am note arguing that NAT will win - my point is that if people want it the resistance is futile. > > 1) Clearly show the advantages of end-to-end and no NAT model. > 2) Have the specs indicating that an IPv6 node (host/router, whatever) MUST NOT support NAT or equivalent mechanisms. Any > interoperability/conformance test must fail if you fail to agree with this specification. This should be a clear sign for the > manufacturers to avoid supporting NATs. > 3) Indicate that if someone wants to keep using NAT, should do it with IPv4. > > I'm not sure if the rest agree and what is the correct document to say this, > may be as part of the changes for the local-link > deprecation ? > > Regards, > Jordi Thanks, Aleksey BTW, I prepared a draft which spells out NAT6, it is absolutely trivial thing compaing to NAT4, so if somebody would want it, they would not need any permissions. > > > ***************************** > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Register at: > http://www.ipv6-es.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 20 17:20:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L1Kd7f027120; Thu, 20 Mar 2003 17:20:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L1Kdqm027119; Thu, 20 Mar 2003 17:20:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L1KZ7f027112 for ; Thu, 20 Mar 2003 17:20:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L1KijO007569 for ; Thu, 20 Mar 2003 17:20:44 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29993 for ; Thu, 20 Mar 2003 17:20:38 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:20:38 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:20:37 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:20:37 Z Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:20:37 Z Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.8/8.12.8) with ESMTP id h2L1KaOr016693 for ; Thu, 20 Mar 2003 17:20:36 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 20 Mar 2003 17:20:36 -0800 Received: from apple.com (graejo4.apple.com [17.202.40.114]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h2L1KaH11851 for ; Thu, 20 Mar 2003 17:20:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v565) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6909326D-5B3B-11D7-A6B1-000393C3FE6A@apple.com> Content-Transfer-Encoding: 7bit From: Joshua Graessley Subject: Re: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 17:21:15 -0800 To: ipng@sunroof.eng.sun.com X-Mailer: Apple Mail (2.565) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this may be looking at the problem in the wrong way. The one compelling reason to get IPv6, in my opinion, is because it restores the end to end connectivity. IPv6 has enough addresses and ISP can give me my own block that I can assign to various devices in my apartment. The compelling part of IPv6 is that eliminates the need for me to have a NAT. If it weren't for NAT, Ipv4 works well enough, and we don't need IPv6. I would expect that the killer applications for IPv6 will be the ones that take advantage of IPv6's end to end connectivity. If some bozo does try to implement a NAT for IPv6, it will break those applications that make IPv6 compelling. As an implementor of certain bits of software shipping with a mainstream operating system, I will do my part to make sure that no NAT traversal solutions for various pieces work with IPv6. I've recently been working on IPSec NAT Traversal. The spec notes how the protocol can detect and work around NATs on IPv4 and IPv6. Our implementation intentionally does not support NAT traversal over IPv6. If we can eliminate all of the gross hacks to make software work with NATs in the IPv6 versions, we could create a world in which a NAT can not be deployed because it breaks too much stuff. A vendor could not sell an IPv6 NAT in to such a world. -josh On Thursday, March 20, 2003, at 5:05PM, Quality Quorum wrote: > > > On Thu, 20 Mar 2003, JORDI PALET MARTINEZ wrote: > >> After the today's decision with site local, is clear to me that we >> don't >> want to have NAT happening again ;-) >> >> We know that the people will do it anyway, but we must do an effort >> to avoid is as much as possible, and some ideas that could >> support this are: > > IETF is big and strong, market[lace is much bigger and much stronger, > in > all previous collisions with market IETF did not fare well. > > Note - I am note arguing that NAT will win - my point is that if people > want it the resistance is futile. > > >> >> 1) Clearly show the advantages of end-to-end and no NAT model. >> 2) Have the specs indicating that an IPv6 node (host/router, >> whatever) MUST NOT support NAT or equivalent mechanisms. Any >> interoperability/conformance test must fail if you fail to agree with >> this specification. This should be a clear sign for the >> manufacturers to avoid supporting NATs. >> 3) Indicate that if someone wants to keep using NAT, should do it >> with IPv4. >> >> I'm not sure if the rest agree and what is the correct document to >> say this, >> may be as part of the changes for the local-link >> deprecation ? >> >> Regards, >> Jordi > > Thanks, > > Aleksey > > BTW, I prepared a draft which spells out NAT6, it is absolutely trivial > thing compaing to NAT4, so if somebody would want it, they would not > need any permissions. > >> >> >> ***************************** >> Madrid 2003 Global IPv6 Summit >> 12-14 May 2003 - Register at: >> http://www.ipv6-es.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 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > 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 Thu Mar 20 17:38:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L1cL7f027528; Thu, 20 Mar 2003 17:38:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L1cLEk027527; Thu, 20 Mar 2003 17:38:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L1cI7f027520 for ; Thu, 20 Mar 2003 17:38:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L1cQjO013096 for ; Thu, 20 Mar 2003 17:38:27 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23382 for ; Thu, 20 Mar 2003 18:38:21 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:38:21 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:38:21 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:38:20 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 01:38:20 Z Content-class: urn:content-classes:message Subject: RE: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 17:38:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D0A@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcLvR2FM9JRbkXyvTU2ZeqXvqzkAbgAAgxBQ From: "Michel Py" To: "Quality Quorum" , "Jordi Palet Martinez" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2L1cI7f027521 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Aleksey wrote: > BTW, I prepared a draft which spells out NAT6 If you're tired of life, there probably are better ways to go than being lynched by a crowd of IETFers. Michel. -------------------------------------------------------------------- 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 Mar 20 18:00:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L20s7f027760; Thu, 20 Mar 2003 18:00:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L20sIa027759; Thu, 20 Mar 2003 18:00:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L20p7f027752 for ; Thu, 20 Mar 2003 18:00:51 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L210cU027078 for ; Thu, 20 Mar 2003 18:01:00 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06875 for ; Thu, 20 Mar 2003 18:00:54 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:00:53 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:00:53 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:00:53 Z Received: from TheWorld.com ([199.172.62.103] [199.172.62.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:00:52 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8/8.12.8) with ESMTP id h2L20eS1032430; Thu, 20 Mar 2003 21:00:40 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id VAA6030961; Thu, 20 Mar 2003 21:00:41 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Thu, 20 Mar 2003 21:00:41 -0500 From: Quality Quorum To: Michel Py cc: Jordi Palet Martinez , Subject: RE: avoiding NAT with IPv6 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D0A@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Mar 2003, Michel Py wrote: > > Aleksey wrote: > > BTW, I prepared a draft which spells out NAT6 > > If you're tired of life, there probably are better ways to go than being > lynched by a crowd of IETFers. Ever heard about SNMP wars? I highly doubt that by now there is so much fire left anywhere in IETF :) Speaking seriously, it seems to me that people underestimate both how easy is to do NAT6 even without any official blessing and how hard is to fight against market forces. So, it is quite possible that nobody would ever want NAT6, but if there is a desire it will be unstoppable. Moreover, the only result of special measures making NAT6 harder to do will result in more starving companines trying to differenciate themselves by providing workarounds. IMHO being NAT6-neutral/NAT6-friendly would at least reduce its commercial attractivness (similar to drug legalization). BTW, giving every organization /48 will lead to a pretty big routing tables. > Michel. Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 20 18:05:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L25r7f027949; Thu, 20 Mar 2003 18:05:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L25qeY027948; Thu, 20 Mar 2003 18:05:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L25n7f027941 for ; Thu, 20 Mar 2003 18:05:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L25wcU028333 for ; Thu, 20 Mar 2003 18:05:58 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09660 for ; Thu, 20 Mar 2003 18:05:51 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:05:50 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:05:46 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:05:45 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:05:45 Z Content-class: urn:content-classes:message Subject: RE: avoiding NAT with IPv6 Date: Thu, 20 Mar 2003 18:05:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D0B@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcLvTbFUM+TBqiUBS4W6RgEl9atSzQAABMAQ From: "Michel Py" To: "Quality Quorum" Cc: "Jordi Palet Martinez" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2L25n7f027942 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Aleksey wrote: > Speaking seriously, it seems to me that people underestimate > both how easy is to do NAT6 even without any official > blessing and how hard is to fight against market forces. Not me. I mostly agree with the "resistance is futile" you posted earlier. That being said, it's not a reason to encourage it. > IMHO being NAT6-neutral/NAT6-friendly would at least > reduce its commercial attractivness (similar to drug > legalization). I have to disagree with this for NAT6. Michel. -------------------------------------------------------------------- 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 Mar 20 18:08:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L2867f028026; Thu, 20 Mar 2003 18:08:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L2863U028025; Thu, 20 Mar 2003 18:08:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L2827f028015 for ; Thu, 20 Mar 2003 18:08:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L28BjO020742 for ; Thu, 20 Mar 2003 18:08:11 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA04093 for ; Thu, 20 Mar 2003 19:08:01 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:07:58 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:07:57 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:07:57 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:07:55 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 33C3B22D4; Thu, 20 Mar 2003 21:07:52 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 21:07:52 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 21:07:51 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD8A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLvM3kW9a2yy1OSS4Srkp95ZoF3cgAGkgGw From: "Bound, Jim" To: "Pekka Savola" Cc: , X-OriginalArrivalTime: 21 Mar 2003 02:07:52.0026 (UTC) FILETIME=[ADAFC3A0:01C2EF4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2L2827f028016 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Correct. Also as a note solving an engineering problem for the non typical user can result in more profit than the typical, and why it does interest me. But I see your point. For some reason I thought this doc was a standards track its not. Its BCP. So now I care less from an appeal perspective. But I still think stateful is a SHOULD just like I thought sitelocal was not needed 5 years ago and DHCPv6 was needed and many did not want that to happen either. They learned. The market will decide at the end of the day. Stateful will be used initially more than statless except for handhelds and roaming devices and for stateless ad hoc deployment architectures which I admit is the majority of what I am working on now in the IPv6 user community. Stateless has new "operational" advantage IPv4 does not. Ergo a lot of people are chomping on the bit to use it. And to a point where you and I to not agree again. Those people are going to move to IPv6 far faster than we think here. They will build immediate IPv6 Intranet or Private-Internet IPv6 backbones. And they want DSTM :---). But we will do it for them out of here don't worry :--) /jim Thanks /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, March 20, 2003 5:53 PM > To: Bound, Jim > Cc: john.loughney@nokia.com; ipng@sunroof.eng.sun.com > Subject: RE: Mobility in Nodes Requirements > > > On Thu, 20 Mar 2003, Bound, Jim wrote: > > > > A server in a helicopter or plane is mobile for a few > > > applications. I > > > > understand I am trying to make a point that this exercise > > > needs to be > > > > focused on more than the term "node". > > > > > > Such is hardly a minimal or even typical case of IPv6. > > > > So you only want to work on the typical case in the IETF? > > > > It appears you do not care about the non typical? > > No, but we certainly *must* consider what's typical when setting > *requirements* for *all* nodes. > > Non-typical cases are fine -- and will be used, that's great, > the more IPv6 the better -- but I don't see why such should > set what the mainline does. > > I can easily envision server on a helicopter. That's a case, > of course. > But something that must be taken into consideration when > implementing the helicopter and the server. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- 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 Mar 20 18:09:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L2947f028112; Thu, 20 Mar 2003 18:09:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L293RT028111; Thu, 20 Mar 2003 18:09:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L28w7f028093 for ; Thu, 20 Mar 2003 18:08:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L296cU029694 for ; Thu, 20 Mar 2003 18:09:06 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23520 for ; Thu, 20 Mar 2003 19:09:01 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:09:00 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:06:20 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:09:00 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:08:59 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 91DAC232C; Thu, 20 Mar 2003 21:08:59 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 21:08:59 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 21:08:59 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD8B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLvM9ujix+LjkPCSbabRh7Yw8koawAGt/0Q From: "Bound, Jim" To: "Pekka Savola" Cc: "Jari Arkko" , , X-OriginalArrivalTime: 21 Mar 2003 02:08:59.0400 (UTC) FILETIME=[D5D83880:01C2EF4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2L28w7f028095 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Not clear what the goal is. But am clear what made it happen and that was 3GPP. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, March 20, 2003 5:56 PM > To: Bound, Jim > Cc: Jari Arkko; john.loughney@nokia.com; ipng@sunroof.eng.sun.com > Subject: RE: Mobility in Nodes Requirements > > > On Thu, 20 Mar 2003, Bound, Jim wrote: > > This document started because the 3GPP vendors did not want > to do all > > the musts in the RFCs. Fine so lets just make this a 3GPP document > > which it was in the first place. > > I thought the issue was more about *WHICH* RFC's to > implement, no which > MUSTs (or whatever) to ignore in those RFC's they intend to implement. > > The same applies in node reqs, I think. > > > > -----Original Message----- > > > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > > > Sent: Wednesday, March 19, 2003 12:30 PM > > > To: john.loughney@nokia.com > > > Cc: Bound, Jim; ipng@sunroof.eng.sun.com > > > Subject: Re: Mobility in Nodes Requirements > > > > > > > > > john.loughney@nokia.com wrote: > > > > Jim, > > > > > > > > > > > >>>I don't believe that servers, for example, need to implement > > > >>>mobile node functionality. If a node is fixed and > will not move, > > > >>>what use is mobile node functionality? > > > >> > > > >>A server in a helicopter or plane is mobile for a few > > > applications. I > > > >>understand I am trying to make a point that this exercise > > > needs to be > > > >>focused on more than the term "node". > > > > > > > > > > > > So, perhaps I should have said 'Nodes which change their IP > > > addresses, > > > > for example base on Mobile IP, MUST implement mobile node > > > > functionality.' > > > > > > > > Would that kind of text cover your needs. > > > > > > This is a circular definition. The issue is that a node might > > > not know whether its attachment to a network is going to > > > change or not. Those that get these changes, could use mobile > > > IPv6 to deal with it and still keep sessions flowing. > > > > > > Jim may have a point here about the server in a helicopter. > > > But where do we draw the limit? How do we know that 3000 kg > > > IBM mainframe isn't being flown around in a cargo aircraft? > > > Also, the type of the interface on the device may have > > > significance. Or the application; a sensor reporting its > > > findings using a single packet would not need mobility. > > > > > > In conclusion I don't think we can base the mobile node > > > support requirement on the above definition. The options that > > > I see are the following: > > > > > > - "Hosts MAY/SHOULD/MUST support mobile node functionality" (the > > > current text uses MAY). > > > > > > - "Hosts SHOULD/MUST support mobile node functionality > ". > > > > > > Here could be e.g. related to the > > > type of the device "on portable devices", or maybe "on devices > > > weighing under 2 kilograms" ;-) > > > > > > We could base it on the type of the interfaces supported, > > > e.g., "on devices that may use wireless interfaces", > > > > > > We could base it on the type of the application, e.g., "on > > > devices that may have applications that require sessions to > > > survive movements". > > > > > > Frankly, I'm not sure it is possible to formulate a good > > > condition for the second option. So I'm inclined to think > > > that its either the current MAY support or possibly SHOULD > > > support. What do people think? > > > > > > >>>>> Hosts SHOULD support route optimization requirements for > > > >>>>> correspondent nodes. Routers do not need to support route > > > >>>>> optimization. > > > >>>>> > > > >>>>> Routers MAY support home agent functionality. > > > >>>> > > > >>>>Routers SHOULD support the HA is correct effort. Otherwise > > > >>>>MIPv6 > > > >>>>don't work. > > > >>> > > > >>>Not all routers need to be Home Agents I don't believe that > > > >>>plain, vanilla routers will be affected by home agent > > > functionality. > > > >> > > > >>Routers that implement MIPv6 SHOULD support HAs. Again > context is > > > >>everything. > > > > > > > > > > > > That text works for me. > > > > > > Uh... that's also a circular definition. Like Pekka noted > > > already, there are two pieces of router functionality > > > (sections 8.3 and 8.4). The current keywords are SHOULD for > > > the AI option etc and MAY for the HA functionality. We can > > > debate these keywords, but I personally think they are fairly > > > close to the right thing. > > > > > > Jari > > > > > > > > > > -------------------------------------------------------------------- > > 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 > > -------------------------------------------------------------------- > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- 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 Mar 20 18:10:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L2A77f028194; Thu, 20 Mar 2003 18:10:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L2A7MW028192; Thu, 20 Mar 2003 18:10:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L2A37f028181 for ; Thu, 20 Mar 2003 18:10:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L2ABcU000381 for ; Thu, 20 Mar 2003 18:10:11 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24042 for ; Thu, 20 Mar 2003 19:10:06 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:10:05 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:07:25 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:10:05 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:10:04 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7E63022E8; Thu, 20 Mar 2003 21:10:04 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 20 Mar 2003 21:10:04 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Mobility in Nodes Requirements Date: Thu, 20 Mar 2003 21:10:04 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD8C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLvOGdPN4wGqMdfTKqB4JIgvNeXRgAFoMHg From: "Bound, Jim" To: "Pekka Savola" , "Tim Hartrick" Cc: , X-OriginalArrivalTime: 21 Mar 2003 02:10:04.0414 (UTC) FILETIME=[FC9891E0:01C2EF4E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2L2A37f028182 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It is only for BCP. Not PS. I just found that out this week per my last mail. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, March 20, 2003 6:28 PM > To: Tim Hartrick > Cc: jari.arkko@kolumbus.fi; Bound, Jim; ipng@sunroof.eng.sun.com > Subject: RE: Mobility in Nodes Requirements > > > On Thu, 20 Mar 2003, Tim Hartrick wrote: > > In general, I agree with Jim here. I have never seen the > need for an > > IPv6 node requirements specification. The need for the IPv4 host > > requirements document was in large part driven by the large > number of > > ambiguities and bugs in the original IPv4 RFCs. [...] > > I agree, at least to a degree: I believe the optimal category > should be BCP or Informational. PS (as is currently in the > charter) is also fine, though I see little which would > require this -- and in fact might give a wrong picture of the > nature of the memo. > > But this is a discussion we probably have had many times -- > too bad I just > remember the outcome and justifications (well, one: IPv4 > NodeReqs was PS > for reasons given by Tim). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -------------------------------------------------------------------- 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 Mar 20 18:35:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L2Z87f029226; Thu, 20 Mar 2003 18:35:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L2Z80v029225; Thu, 20 Mar 2003 18:35:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L2Z47f029218 for ; Thu, 20 Mar 2003 18:35:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L2ZDcU011634 for ; Thu, 20 Mar 2003 18:35:13 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA20592 for ; Thu, 20 Mar 2003 19:35:07 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:35:07 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:35:07 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:35:06 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 02:35:06 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5AD29137F05; Thu, 20 Mar 2003 18:35:04 -0800 (PST) Date: Thu, 20 Mar 2003 18:35:03 -0800 Subject: Re: avoiding NAT with IPv6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "JORDI PALET MARTINEZ" From: David Conrad In-Reply-To: <0c1001c2eede$bb97e6c0$e48c8182@consulintel.es> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, One of the primary uses of NAT is to provide provider (and registry) independence. It also provides a way to get around ISP restrictions on the number of devices customers can connect to a network. Off the top of my head, I believe as long as any of the following are true: - you must renumber if you change service providers - renumbering requires any effort whatsoever from the end user - renumbering interrupts services in any way - requesting addresses requires any formal process or procedures you will have NAT, regardless of whether it is IPv4 or IPv6. Attempting to legislate behavior through non-binding standards activities contrary to customer desires is a waste of everyone's time. Rgds, -drc On Thursday, March 20, 2003, at 04:46 AM, JORDI PALET MARTINEZ wrote: > Yes, agree, but the constructive solution is IPv6 itself. We need to > show it (probably out of the scope of the IETF). > > We need also to understand other reasons why NAT is there and provide > solutions, if not available with today's IPv6. We know that > NAT is used because disconnected networks become connected, because > false security impression, and because the lack of enough > addressing space. What other reasons are to use NAT ? > > Jordi > > ----- Original Message ----- > From: "BINET David FTRD/DMI/CAE" > To: "JORDI PALET MARTINEZ" ; > > Sent: Thursday, March 20, 2003 9:53 PM > Subject: RE: avoiding NAT with IPv6 > > >> Hello, >> >>> After the today's decision with site local, is clear to me >>> that we don't want to have NAT happening again ) >> I think it was clear before SL discussion. >>> >>> We know that the people will do it anyway, but we must do an >>> effort to avoid is as much as possible, and some ideas that could >>> support this are: >>> >>> 1) Clearly show the advantages of end-to-end and no NAT model. >>> 2) Have the specs indicating that an IPv6 node (host/router, >>> whatever) MUST NOT support NAT or equivalent mechanisms. Any >>> interoperability/conformance test must fail if you fail to >>> agree with this specification. This should be a clear sign for the >>> manufacturers to avoid supporting NATs. >>> 3) Indicate that if someone wants to keep using NAT, should >>> do it with IPv4. >> The good question is: why customers use NATs ? >> Maybe, it is because of the lack of public addresses and surely there >> are some other reasons ! >> So I am not convinced by the interdiction of NATs in IPv6 node >> requirements >> (is it possible ?) but I would prefer a constructive solution that >> provides >> right solutions for customer needs. End to end secure communications >> is a >> nice goal but is it possible today to propose such service for any >> customer or >> in any environment ? >>> >>> I'm not sure if the rest agree and what is the correct >>> document to say this, may be as part of the changes for the >>> local-link >>> deprecation ? >>> >>> Regards, >>> Jordi >> David >>> >>> >>> ***************************** >>> Madrid 2003 Global IPv6 Summit >>> 12-14 May 2003 - Register at: >>> http://www.ipv6-es.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 >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> 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 >> -------------------------------------------------------------------- >> > > > ***************************** > Madrid 2003 Global IPv6 Summit > 12-14 May 2003 - Register at: > http://www.ipv6-es.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 Mar 20 19:28:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L3Sq7f029531; Thu, 20 Mar 2003 19:28:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L3Sqka029530; Thu, 20 Mar 2003 19:28:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L3Sn7f029523 for ; Thu, 20 Mar 2003 19:28:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L3SvjO010846 for ; Thu, 20 Mar 2003 19:28:57 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA05460 for ; Thu, 20 Mar 2003 20:28:50 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 03:28:49 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 03:26:04 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 03:28:44 Z Received: from ALPHA1.ITS.MONASH.EDU.AU (ALPHA1.ITS.MONASH.EDU.AU [130.194.1.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 03:28:43 Z Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KTSFLPQUHM95OW45@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 14:27:44 +1100 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id E368920011; Fri, 21 Mar 2003 14:27:43 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id C342F20010; Fri, 21 Mar 2003 14:27:43 +1100 (EST) Date: Fri, 21 Mar 2003 14:27:43 +1100 From: Greg Daley Subject: Re: avoiding NAT with IPv6 To: Quality Quorum Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E7A86AF.5080408@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Aleksey Quality Quorum wrote: > > On Thu, 20 Mar 2003, Michel Py wrote: > > >>>Aleksey wrote: >>>BTW, I prepared a draft which spells out NAT6 >> >>If you're tired of life, there probably are better ways to go than being >>lynched by a crowd of IETFers. > > > Ever heard about SNMP wars? I highly doubt that by now there is so much > fire left anywhere in IETF :) > > Speaking seriously, it seems to me that people underestimate both how easy > is to do NAT6 even without any official blessing and how hard is to fight > against market forces. > > So, it is quite possible that nobody would ever want NAT6, but if there > is a desire it will be unstoppable. Moreover, the only result of special > measures making NAT6 harder to do will result in more starving companines > trying to differenciate themselves by providing workarounds. > > IMHO being NAT6-neutral/NAT6-friendly would at least reduce its > commercial attractivness (similar to drug legalization). > I'm pretty sure this would cripple any (reasonable) end-to-end assumptions people may want to make with programming IPv6 apps. Please, think of your children when asking us to support NAT. We're trying to make the Internet a system which will support the applications we need in 2020, not 1999. I'm not advocating "fight against the tide", but initially IPv6 can be marketed as better than IPv4 because of NAT4. Once IPv6 starts taking off, then it's our job to educate people about NAT being evil. We shouldn't be accomodating it now. Greg -------------------------------------------------------------------- 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 Mar 20 20:07:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L47s7f029984; Thu, 20 Mar 2003 20:07:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L47s89029983; Thu, 20 Mar 2003 20:07:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L47o7f029976 for ; Thu, 20 Mar 2003 20:07:50 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L47xcU006340 for ; Thu, 20 Mar 2003 20:07:59 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05906 for ; Thu, 20 Mar 2003 20:07:53 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:07:53 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:07:53 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:07:52 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:07:52 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2L46QM02923 for ; Fri, 21 Mar 2003 06:06:26 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Mar 2003 06:07:51 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Mar 2003 06:07:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Mobility in Nodes Requirements Date: Fri, 21 Mar 2003 06:07:49 +0200 Message-Id: <245DBCAEEC4F074CB77B3F984FF9834FDC3831@esebe005.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLvOTSMnjkEvpEKR4q88brY1/McVgAJXL7g To: , X-OriginalArrivalTime: 21 Mar 2003 04:07:51.0066 (UTC) FILETIME=[70A617A0:01C2EF5F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2L47p7f029977 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Pekka et co.! Actually, the current charter says: http://www.ietf.org/html.charters/ipv6-charter.html "APR 03 Submit IPv6 Node Requirements to IESG for Informational." I also think that Info (or BCP) is the correct category. Cheers, -Juha- -----Original Message----- From: ext Pekka Savola [mailto:pekkas@netcore.fi] Sent: 21 March, 2003 01:28 To: Tim Hartrick Cc: jari.arkko@kolumbus.fi; Jim.Bound@hp.com; ipng@sunroof.eng.sun.com Subject: RE: Mobility in Nodes Requirements On Thu, 20 Mar 2003, Tim Hartrick wrote: > In general, I agree with Jim here. I have never seen the need for an > IPv6 node requirements specification. The need for the IPv4 host requirements > document was in large part driven by the large number of ambiguities and > bugs in the original IPv4 RFCs. [...] I agree, at least to a degree: I believe the optimal category should be BCP or Informational. PS (as is currently in the charter) is also fine, though I see little which would require this -- and in fact might give a wrong picture of the nature of the memo. But this is a discussion we probably have had many times -- too bad I just remember the outcome and justifications (well, one: IPv4 NodeReqs was PS for reasons given by Tim). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Thu Mar 20 20:12:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L4CI7f000172; Thu, 20 Mar 2003 20:12:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L4CIjE000171; Thu, 20 Mar 2003 20:12:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L4CE7f000151 for ; Thu, 20 Mar 2003 20:12:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L4CNjO018872 for ; Thu, 20 Mar 2003 20:12:23 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15513 for ; Thu, 20 Mar 2003 21:12:17 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:12:17 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:06:29 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:09:09 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 04:09:08 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2L495A06733; Fri, 21 Mar 2003 06:09:05 +0200 Date: Fri, 21 Mar 2003 06:09:05 +0200 (EET) From: Pekka Savola To: juha.wiljakka@nokia.com cc: ipng@sunroof.eng.sun.com Subject: RE: Mobility in Nodes Requirements In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834FDC3831@esebe005.ntc.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Mar 2003 juha.wiljakka@nokia.com wrote: > Hi, Pekka et co.! > > Actually, the current charter says: > http://www.ietf.org/html.charters/ipv6-charter.html > > "APR 03 Submit IPv6 Node Requirements to IESG for Informational." > > I also think that Info (or BCP) is the correct category. Oh, must have misread -- thanks. > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 21 March, 2003 01:28 > To: Tim Hartrick > Cc: jari.arkko@kolumbus.fi; Jim.Bound@hp.com; ipng@sunroof.eng.sun.com > Subject: RE: Mobility in Nodes Requirements > > > On Thu, 20 Mar 2003, Tim Hartrick wrote: > > In general, I agree with Jim here. I have never seen the need for an > > IPv6 node requirements specification. The need for the IPv4 host requirements > > document was in large part driven by the large number of ambiguities and > > bugs in the original IPv4 RFCs. [...] > > I agree, at least to a degree: I believe the optimal category should be > BCP or Informational. PS (as is currently in the charter) is also fine, > though I see little which would require this -- and in fact might give a > wrong picture of the nature of the memo. > > But this is a discussion we probably have had many times -- too bad I just > remember the outcome and justifications (well, one: IPv4 NodeReqs was PS > for reasons given by Tim). > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 20 22:08:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L68Q7f000792; Thu, 20 Mar 2003 22:08:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L68Qdn000791; Thu, 20 Mar 2003 22:08:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L68N7f000784 for ; Thu, 20 Mar 2003 22:08:23 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L68WjO011586 for ; Thu, 20 Mar 2003 22:08:32 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11564 for ; Thu, 20 Mar 2003 22:08:26 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:08:25 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:08:23 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:08:23 Z Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:08:23 Z Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2L68LD22199 for ; Fri, 21 Mar 2003 00:08:21 -0600 (CST) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H2D5PPHC; Fri, 21 Mar 2003 00:08:21 -0600 Received: from iqmail.net (CHOWDURY-2 [47.81.5.25]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GSPRQFN7; Fri, 21 Mar 2003 00:08:20 -0600 Message-Id: <3E7AAC51.9000009@iqmail.net> Date: Fri, 21 Mar 2003 00:08:17 -0600 X-Sybari-Space: 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: DAD in node requirements draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I would like to clarify this text in section 4.2: " Duplicate Address Detection MUST be supported (RFC2462 section 5.4 specifies DAD MUST take place on all unicast addresses). " Although the relevant section in RFC2462 makes DAD a MUST for unicast addresses there are also some exceptions in the same section based on link layer. Also RFC 2472 makes DAD redundant for PPP links. Therefore I would like to see the following clarification: " Duplicate Address Detection MUST be supported as specified in RFC2462 section 5.4 for non PPP links. " Comments? -Kuntal -------------------------------------------------------------------- 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 Mar 20 22:15:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L6Fh7f001053; Thu, 20 Mar 2003 22:15:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L6FhBc001052; Thu, 20 Mar 2003 22:15:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L6Fc7f001041 for ; Thu, 20 Mar 2003 22:15:39 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2L6FbK25141; Fri, 21 Mar 2003 07:15:38 +0100 (MET) Date: Fri, 21 Mar 2003 07:11:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API To: Francis Dupont Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com In-Reply-To: "Your message with ID" <200303202339.h2KNdCof061873@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What I propose is to put the policy in the context of applications > (Unix user structure, environment, etc, even monitors have this kind > of things) so one can tune the address selection before launching > applications. When the context can be managed from applications > (the usual case), this makes [gs]etsockopt() no more necessary. > And global flags can be replaced by default values... Having per-application or per-process overrides of anything if rife with issues since an application isn't a single unit; it consists of several independently developped pieces (libraries being the main source of the many pieces). Thus while the developper know that the pieces s/he has written want to turn the knob to affect the sockets in that piece of code, making the knob be per-process means that it will also affect sockets in libraries. Thus turning the per-process knob can have unknown side effects. Hence the need to have a per-socket knob. 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 Thu Mar 20 22:19:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L6Jb7f001148; Thu, 20 Mar 2003 22:19:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L6JbuI001147; Thu, 20 Mar 2003 22:19:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L6JX7f001138 for ; Thu, 20 Mar 2003 22:19:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L6JfjO014130 for ; Thu, 20 Mar 2003 22:19:41 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22877 for ; Thu, 20 Mar 2003 23:19:35 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:19:34 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:19:32 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:19:32 Z Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 06:19:31 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A44734FA4; Fri, 21 Mar 2003 15:19:24 +0900 (JST) To: Kuntal Chowdhury Cc: ipng@sunroof.eng.sun.com In-reply-to: kuntal's message of Fri, 21 Mar 2003 00:08:17 CST. <3E7AAC51.9000009@iqmail.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DAD in node requirements draft From: itojun@iijlab.net Date: Fri, 21 Mar 2003 15:19:24 +0900 Message-Id: <20030321061924.A44734FA4@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Although the relevant section in RFC2462 makes DAD a MUST for unicast addresses >there are also some exceptions in the same section based on link layer. Also RFC >2472 makes DAD redundant for PPP links. Therefore I would like to see the >following clarification: > >" >Duplicate Address Detection MUST be supported as specified in RFC2462 section 5.4 >for non PPP links. >" >Comments? for link-local address RFC2472 exception makes sense, but for others it does not. i'd say keep node-req text as is. itojun -------------------------------------------------------------------- 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 Mar 21 01:11:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L9Br7f001843; Fri, 21 Mar 2003 01:11:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2L9Brbo001842; Fri, 21 Mar 2003 01:11:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2L9Bn7f001835 for ; Fri, 21 Mar 2003 01:11:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2L9BwjO016167 for ; Fri, 21 Mar 2003 01:11:58 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA16930 for ; Fri, 21 Mar 2003 02:11:49 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 09:11:48 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 09:11:47 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 09:11:47 Z Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 09:11:47 Z Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HC300M01DJLTM@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 18:11:45 +0900 (KST) Received: from ep_mmp2 ([127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HC300M3EDJLE8@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 18:11:45 +0900 (KST) Received: from praveen ([107.108.4.247]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HC3008YUDJI1J@mmp2.samsung.com> for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 18:11:45 +0900 (KST) Date: Fri, 21 Mar 2003 14:39:55 +0530 From: Praveen Rajendran Subject: Re: Mobility in Nodes Requirements To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Message-Id: <011e01c2ef89$a5252c30$f7046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi The node requirements draft has some requirements which "MAY" be supported. However in the absence of some rigidity ( MUST or SHOULD ) these requirements do not convey any information. A requirement like "IPv6 Jumbograms [RFC2675] MAY be supported." is as good as its absence from the draft altogether. The draft in its introduction says "Many IPv6 nodes will implement optional or additional features, but all IPv6 nodes can be expected to implement the mandatory requirements listed in this document." Should the draft stick to only those reqirements that are essential and steer clear of the others ?? After all it might be tough to capture all optional features in the draft. regards Praveen ----- Original Message ----- From: To: Cc: Sent: Friday, March 21, 2003 5:07 AM Subject: RE: Mobility in Nodes Requirements > Hi all, > > > I agree, at least to a degree: I believe the optimal category should be > > BCP or Informational. PS (as is currently in the charter) is also fine, > > though I see little which would require this -- and in fact might give a > > wrong picture of the nature of the memo. > > My opinion is that the document should be a BCP. Hopefully, > the chairs could confirm or deny this. > > > But this is a discussion we probably have had many times -- too bad I just > > remember the outcome and justifications (well, one: IPv4 NodeReqs was PS > > for reasons given by Tim). > > IPv4 Node Req predated PS, etc. notations, I think. > > John > > -------------------------------------------------------------------- > 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 Fri Mar 21 02:41:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LAfo7f002392; Fri, 21 Mar 2003 02:41:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LAfoNI002391; Fri, 21 Mar 2003 02:41:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LAfi7f002377 for ; Fri, 21 Mar 2003 02:41:44 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LAfqjO000629 for ; Fri, 21 Mar 2003 02:41:52 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22283 for ; Fri, 21 Mar 2003 02:41:47 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 10:41:46 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 10:41:43 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 10:41:43 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 10:41:43 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 1800589EF; Fri, 21 Mar 2003 11:41:39 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 37124898A; Fri, 21 Mar 2003 11:41:33 +0100 (CET) From: "Jeroen Massar" To: "'Quality Quorum'" , "'Michel Py'" Cc: "'Jordi Palet Martinez'" , Subject: RE: avoiding NAT with IPv6 Date: Fri, 21 Mar 2003 11:42:31 +0100 Organization: Unfix Message-Id: <001d01c2ef96$94167db0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2LAfi7f002378 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quality Quorum wrote: > On Thu, 20 Mar 2003, Michel Py wrote: > > > > Aleksey wrote: > > > BTW, I prepared a draft which spells out NAT6 > > > > If you're tired of life, there probably are better ways to > go than being > > lynched by a crowd of IETFers. > > Ever heard about SNMP wars? I highly doubt that by now there > is so much fire left anywhere in IETF :) /me puts on his DareDevil suit, hmmm no radar but unlike the real DareDevil I can see and kick your .... :) Or to quote some others: send in the clones. > IMHO being NAT6-neutral/NAT6-friendly would at least reduce its > commercial attractivness (similar to drug legalization). Don't say anything about drug legalization when you don't live in the Netherlands. 80% of the Dutch Nederwiet is destined for export. Thus allowing it only makes it worse. > BTW, giving every organization /48 will lead to a pretty big routing > tables. You are avoiding the fact that 'organizations' (the people getting /48's) get that /48 out of a /32 from their upstream and that the routing table _should_ be filtered on those boundaries Maybe you could take a look at http://www.sixxs.net/tools/grh/lg/ which, thanks to Gert Doering contains BGP data back to 25 Aug 2001. The routing tables are getting cleaner by the day. See also Gert's presentations at RIPE: http://www.space.net/~gert/RIPE/ and his Filtering list: http://www.space.net/~gert/RIPE/ipv6-filters.html If you are talking about Multihoming etc, I am sure Michel Py can enlighten you about it. They have been making great hops of progress the last couple of weeks. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 21 04:30:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCUw7f002901; Fri, 21 Mar 2003 04:30:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LCUwgN002900; Fri, 21 Mar 2003 04:30:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCUt7f002893 for ; Fri, 21 Mar 2003 04:30:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LCV2jO017539 for ; Fri, 21 Mar 2003 04:31:03 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29302 for ; Fri, 21 Mar 2003 05:30:57 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:30:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:28:15 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:30:56 Z Received: from TheWorld.com ([199.172.62.103] [199.172.62.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:30:55 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8/8.12.8) with ESMTP id h2LCUnS1022316; Fri, 21 Mar 2003 07:30:49 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id HAA6008240; Fri, 21 Mar 2003 07:30:49 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Fri, 21 Mar 2003 07:30:48 -0500 From: Quality Quorum To: Greg Daley cc: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 In-Reply-To: <3E7A86AF.5080408@eng.monash.edu.au> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Mar 2003, Greg Daley wrote: > I'm pretty sure this would cripple any (reasonable) > end-to-end assumptions people may want to make with > programming IPv6 apps. I do not think so. > > Please, think of your children when asking us to > support NAT. We're trying to make the Internet a system which > will support the applications we need in 2020, not 1999. If you are making assumptions that there will be no NAT6, but it may be forced on us by the market, it is you who are crippling the Internet of the future. > > I'm not advocating "fight against the tide", but > initially IPv6 can be marketed as better than IPv4 > because of NAT4. Once IPv6 starts taking off, then > it's our job to educate people about NAT being evil. If you are successful there will be no NAT6 even it if it is supported, however if you are unsuccessful the damage done by the no-NAT6 decision will be significant. > We shouldn't be accomodating it now. Your own argument points the other way - if we are thinking about future we should not artificially cripple the environment now. > Greg Anyway, I suppose the issue had been discussed enough. Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 21 04:34:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCYX7f002966; Fri, 21 Mar 2003 04:34:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LCYXuS002965; Fri, 21 Mar 2003 04:34:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCYU7f002958 for ; Fri, 21 Mar 2003 04:34:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LCYbjO018197 for ; Fri, 21 Mar 2003 04:34:37 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16784 for ; Fri, 21 Mar 2003 05:34:32 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:34:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:34:31 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:34:31 Z Received: from TheWorld.com ([199.172.62.103] [199.172.62.103]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:34:31 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8/8.12.8) with ESMTP id h2LCYOS1027116; Fri, 21 Mar 2003 07:34:24 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id HAA6102129; Fri, 21 Mar 2003 07:34:24 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Fri, 21 Mar 2003 07:34:23 -0500 From: Quality Quorum To: Jeroen Massar cc: "'Michel Py'" , "'Jordi Palet Martinez'" , Subject: RE: avoiding NAT with IPv6 In-Reply-To: <001d01c2ef96$94167db0$210d640a@unfix.org> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Mar 2003, Jeroen Massar wrote: > You are avoiding the fact that 'organizations' (the people getting > /48's) > get that /48 out of a /32 from their upstream and that the routing > table _should_ be filtered on those boundaries And how many /48s are in /32 ? > Maybe you could take a look at http://www.sixxs.net/tools/grh/lg/ > which, thanks to Gert Doering contains BGP data back to 25 Aug 2001. > The routing tables are getting cleaner by the day. See also Gert's > presentations at RIPE: http://www.space.net/~gert/RIPE/ and his > Filtering list: http://www.space.net/~gert/RIPE/ipv6-filters.html I would love to beleive you but it may be just an aberration of an early and very limited deployment. > > If you are talking about Multihoming etc, I am sure Michel Py > can enlighten you about it. They have been making great hops > of progress the last couple of weeks. > > Greets, > Jeroen > Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 21 04:49:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCns7f003454; Fri, 21 Mar 2003 04:49:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LCnspT003453; Fri, 21 Mar 2003 04:49:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCnp7f003446 for ; Fri, 21 Mar 2003 04:49:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LCnwcU019350 for ; Fri, 21 Mar 2003 04:49:58 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13392 for ; Fri, 21 Mar 2003 05:49:51 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:48:59 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:48:57 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:48:57 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:48:55 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id BD8A389F7; Fri, 21 Mar 2003 13:48:51 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E1E0D89C1; Fri, 21 Mar 2003 13:48:40 +0100 (CET) From: "Jeroen Massar" To: "'Quality Quorum'" Cc: "'Michel Py'" , "'Jordi Palet Martinez'" , Subject: RE: avoiding NAT with IPv6 Date: Fri, 21 Mar 2003 13:49:38 +0100 Organization: Unfix Message-Id: <006801c2efa8$55fa33c0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2LCnp7f003447 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quality Quorum [mailto:qqi@theworld.com] wrote: > On Fri, 21 Mar 2003, Jeroen Massar wrote: > > > You are avoiding the fact that 'organizations' (the people getting > > /48's) > > get that /48 out of a /32 from their upstream and that the routing > > table _should_ be filtered on those boundaries > > And how many /48s are in /32 ? Though the exact calculation depends on how the administrators of the network distribute this address space across their company. But without that consideration: 2^(128-32-48) = 2^48 = 281474976710656 281.474.976.710.656, let's see how one can pronounce that. 281.474.976 milion 281 billiongazzilion or something? At least anyone can deposit it in eurocents or even centavos on my bankaccount and I will be quite a happy chap for the rest of my live and won't bugger anybody again *ever* :) In other words it should be adequate for most very large ISP's :) And enough for your worst wet bedtime dreams. Also that's the reason why we won't want to see single /48's in the DFZ. > > Maybe you could take a look at http://www.sixxs.net/tools/grh/lg/ > > which, thanks to Gert Doering contains BGP data back to 25 Aug 2001. > > The routing tables are getting cleaner by the day. See also Gert's > > presentations at RIPE: http://www.space.net/~gert/RIPE/ and his > > Filtering list: http://www.space.net/~gert/RIPE/ipv6-filters.html > > I would love to beleive you but it may be just an aberration of > an early and very limited deployment. Can you explain why you think in such a way? Actually I think you might be interrested in some good docs IPv6: http://isoc.nl/activ/cursusmateriaal/2002-Masterclass-IETF-IPv6.ppt http://isoc.nl/activ/cursusmateriaal/2002-Masterclass-IETF-IPv6.sxi First one is Steve Deerings presentation in Powerpoint, second one in Open Office format. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 21 04:53:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCrU7f003568; Fri, 21 Mar 2003 04:53:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LCrTIl003567; Fri, 21 Mar 2003 04:53:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LCrQ7f003560 for ; Fri, 21 Mar 2003 04:53:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LCrXcU019829 for ; Fri, 21 Mar 2003 04:53:34 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08924 for ; Fri, 21 Mar 2003 05:53:28 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:53:28 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:50:46 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:53:27 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 12:53:24 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 0511489F7; Fri, 21 Mar 2003 13:53:20 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 29A0A89C1; Fri, 21 Mar 2003 13:53:14 +0100 (CET) From: "Jeroen Massar" To: "'Jeroen Massar'" , "'Quality Quorum'" Cc: Subject: RE: avoiding NAT with IPv6 Date: Fri, 21 Mar 2003 13:54:12 +0100 Organization: Unfix Message-Id: <007001c2efa8$f9782520$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2LCrQ7f003561 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen Massar wrote: > Quality Quorum [mailto:qqi@theworld.com] wrote: > > > On Fri, 21 Mar 2003, Jeroen Massar wrote: > > > > > You are avoiding the fact that 'organizations' (the people getting > > > /48's) > > > get that /48 out of a /32 from their upstream and that the routing > > > table _should_ be filtered on those boundaries > > > > And how many /48s are in /32 ? > > Though the exact calculation depends on how the administrators > of the network distribute this address space across their company. > > But without that consideration: > 2^(128-32-48) = 2^48 = 281474976710656 > > 281.474.976.710.656, let's see how one can pronounce that. > 281.474.976 milion > 281 billiongazzilion or something? > twohundred and eightyone trillion fourhundred and seventyfour billion ninehundred and seventysix million sevenhundred and tenthousand sixhundred and fifty six Enough I would think, you can mail me for my bankaccount details :) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 21 07:28:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LFSD7f004283; Fri, 21 Mar 2003 07:28:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LFSDwX004282; Fri, 21 Mar 2003 07:28:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LFSA7f004275 for ; Fri, 21 Mar 2003 07:28:10 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LFSIjO020027 for ; Fri, 21 Mar 2003 07:28:18 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25131 for ; Fri, 21 Mar 2003 08:28:12 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:28:12 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:28:11 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:28:11 Z Received: from TheWorld.com ([199.172.62.104] [199.172.62.104]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:28:10 Z Received: from shell.TheWorld.com (arwen@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8/8.12.8) with ESMTP id h2LFS81u018281; Fri, 21 Mar 2003 10:28:08 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id KAA5406166; Fri, 21 Mar 2003 10:28:07 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Fri, 21 Mar 2003 10:28:07 -0500 From: Quality Quorum To: Jeroen Massar cc: ipng@sunroof.eng.sun.com Subject: RE: avoiding NAT with IPv6 In-Reply-To: <007001c2efa8$f9782520$210d640a@unfix.org> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Mar 2003, Jeroen Massar wrote: > Jeroen Massar wrote: > > > Quality Quorum [mailto:qqi@theworld.com] wrote: > > > > > On Fri, 21 Mar 2003, Jeroen Massar wrote: > > > > > > > You are avoiding the fact that 'organizations' (the people getting > > > > /48's) > > > > get that /48 out of a /32 from their upstream and that the routing > > > > table _should_ be filtered on those boundaries > > > > > > And how many /48s are in /32 ? > > > > Though the exact calculation depends on how the administrators > > of the network distribute this address space across their company. > > > > But without that consideration: > > 2^(128-32-48) = 2^48 = 281474976710656 > > > > 281.474.976.710.656, let's see how one can pronounce that. > > 281.474.976 milion > > 281 billiongazzilion or something? > > > > twohundred and eightyone trillion fourhundred and seventyfour > billion ninehundred and seventysix million sevenhundred and > tenthousand sixhundred and fifty six > > Enough I would think, you can mail me for my bankaccount details :) Huh ? It is 64K. > > Greets, > Jeroen > Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 21 07:39:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LFd57f004511; Fri, 21 Mar 2003 07:39:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LFd5q9004510; Fri, 21 Mar 2003 07:39:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LFd27f004503 for ; Fri, 21 Mar 2003 07:39:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LFd9jO022721 for ; Fri, 21 Mar 2003 07:39:09 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06527 for ; Fri, 21 Mar 2003 08:39:01 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:39:00 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:38:59 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:38:59 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 15:38:58 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2LFcoN11274; Fri, 21 Mar 2003 17:38:51 +0200 Date: Fri, 21 Mar 2003 17:38:49 +0200 (EET) From: Pekka Savola To: Praveen Rajendran cc: john.loughney@nokia.com, Subject: Re: Mobility in Nodes Requirements In-Reply-To: <011e01c2ef89$a5252c30$f7046c6b@sisodomain.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 21 Mar 2003, Praveen Rajendran wrote: > The node requirements draft has some requirements which "MAY" be supported. > However in the absence of some rigidity ( MUST or SHOULD ) these > requirements do not convey any information. > > A requirement like "IPv6 Jumbograms [RFC2675] MAY be supported." is as good > as its absence from the draft altogether. > > The draft in its introduction says > "Many IPv6 nodes will implement optional > or additional features, but all IPv6 nodes can be expected to > implement the mandatory requirements listed in this document." > > Should the draft stick to only those reqirements that are essential and > steer clear of the others ?? After all it might be tough to capture all > optional features in the draft. I think it's useful to give a summary of all the relevant specifications, whether MAY or not. NodeReqs would then be a useful "reading list" for an implementor. > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, March 21, 2003 5:07 AM > Subject: RE: Mobility in Nodes Requirements > > > > Hi all, > > > > > I agree, at least to a degree: I believe the optimal category should be > > > BCP or Informational. PS (as is currently in the charter) is also fine, > > > though I see little which would require this -- and in fact might give a > > > wrong picture of the nature of the memo. > > > > My opinion is that the document should be a BCP. Hopefully, > > the chairs could confirm or deny this. > > > > > But this is a discussion we probably have had many times -- too bad I > just > > > remember the outcome and justifications (well, one: IPv4 NodeReqs was PS > > > for reasons given by Tim). > > > > IPv4 Node Req predated PS, etc. notations, I think. > > > > John > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 21 08:22:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGMC7f004874; Fri, 21 Mar 2003 08:22:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LGMCFs004873; Fri, 21 Mar 2003 08:22:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGM87f004866 for ; Fri, 21 Mar 2003 08:22:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LGMFjO004210 for ; Fri, 21 Mar 2003 08:22:15 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29562 for ; Fri, 21 Mar 2003 09:22:08 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:22:06 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:22:02 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:22:02 Z Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:22:01 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id EA4EA50DF; Sat, 22 Mar 2003 01:21:58 +0900 (JST) To: Francis Dupont Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com In-reply-to: Francis.Dupont's message of Fri, 21 Mar 2003 00:52:35 +0100. <200303202352.h2KNqZof061924@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API From: itojun@iijlab.net Date: Sat, 22 Mar 2003 01:21:58 +0900 Message-Id: <20030321162159.EA4EA50DF@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The following flags are added for the ai_flags in addrinfo data >> structure defined in Basic IPv6 Socket API Extension [2]. >> >> AI_PREFER_SRC_HOME >> AI_PREFER_SRC_COA >> AI_PREFER_SRC_TMP >> AI_PREFER_SRC_PUBLIC >> AI_PREFER_SRC_CGA >> AI_PREFER_SRC_NONCGA >=> why _SRC_ ? I don't understand how can flags to getaddrinfo(3) affect source address selection. where does it take effect in the following code? itojun error = getaddrinfo(host, serv, &hints, &res); s = -1; for (ai = res; ai; ai = ai->ai_next) { s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); if (s < 0) continue; if (connect(s, ai->ai_addr, ai->ai_addrlen) < 0) { close(s); s = -1; continue; } break; } if (s < 0) exit(1); /* we have a socket */ -------------------------------------------------------------------- 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 Mar 21 08:29:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGT07f004986; Fri, 21 Mar 2003 08:29:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LGSxZt004985; Fri, 21 Mar 2003 08:28:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGSu7f004978 for ; Fri, 21 Mar 2003 08:28:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LGT4jO005988 for ; Fri, 21 Mar 2003 08:29:04 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19616 for ; Fri, 21 Mar 2003 09:28:58 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:28:58 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP; Fri, 21 Mar 2003 16:26:16 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Fri, 21 Mar 2003 16:28:57 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP; Fri, 21 Mar 2003 16:28:56 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2LGSZw11785; Fri, 21 Mar 2003 18:28:35 +0200 Date: Fri, 21 Mar 2003 18:28:34 +0200 (EET) From: Pekka Savola To: itojun@iijlab.net cc: Francis Dupont , Samita Chakrabarti , , , , Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-Reply-To: <20030321162159.EA4EA50DF@coconut.itojun.org> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 22 Mar 2003 itojun@iijlab.net wrote: > >> The following flags are added for the ai_flags in addrinfo data > >> structure defined in Basic IPv6 Socket API Extension [2]. > >> > >> AI_PREFER_SRC_HOME > >> AI_PREFER_SRC_COA > >> AI_PREFER_SRC_TMP > >> AI_PREFER_SRC_PUBLIC > >> AI_PREFER_SRC_CGA > >> AI_PREFER_SRC_NONCGA > >=> why _SRC_ ? > > I don't understand how can flags to getaddrinfo(3) affect source > address selection. where does it take effect in the following code? getaddrinfo implementation itself? of course, then libc would have to aware of src addresses and such.. > error = getaddrinfo(host, serv, &hints, &res); > s = -1; > for (ai = res; ai; ai = ai->ai_next) { > s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol); > if (s < 0) > continue; > if (connect(s, ai->ai_addr, ai->ai_addrlen) < 0) { > close(s); > s = -1; > continue; > } > break; > } > if (s < 0) > exit(1); > /* we have a socket */ > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 21 08:34:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGYN7f005180; Fri, 21 Mar 2003 08:34:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LGYNil005179; Fri, 21 Mar 2003 08:34:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGYJ7f005172 for ; Fri, 21 Mar 2003 08:34:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LGYQcU011062 for ; Fri, 21 Mar 2003 08:34:27 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16597 for ; Fri, 21 Mar 2003 09:34:20 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:31:37 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:31:37 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:31:37 Z Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:31:36 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E2A9F50E7; Sat, 22 Mar 2003 01:30:58 +0900 (JST) To: Pekka Savola Cc: Francis Dupont , Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com In-reply-to: pekkas's message of Fri, 21 Mar 2003 18:28:34 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API From: itojun@iijlab.net Date: Sat, 22 Mar 2003 01:30:58 +0900 Message-Id: <20030321163058.E2A9F50E7@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I don't understand how can flags to getaddrinfo(3) affect source >> address selection. where does it take effect in the following code? >getaddrinfo implementation itself? of course, then libc would have to >aware of src addresses and such.. getaddrinfo(3) does not open socket, so getaddrinfo(3) cannot perform [gs]etsockopt. itojun -------------------------------------------------------------------- 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 Mar 21 08:49:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGn67f005602; Fri, 21 Mar 2003 08:49:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LGn6Gc005601; Fri, 21 Mar 2003 08:49:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGn37f005591 for ; Fri, 21 Mar 2003 08:49:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LGnAjO013088 for ; Fri, 21 Mar 2003 08:49:10 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22124 for ; Fri, 21 Mar 2003 09:49:04 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:49:03 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:49:03 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:49:03 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 16:49:02 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 720876A906; Fri, 21 Mar 2003 18:48:56 +0200 (EET) Message-Id: <3E7B4246.60702@kolumbus.fi> Date: Fri, 21 Mar 2003 18:48:06 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: Praveen Rajendran , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Mobility in Nodes Requirements References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > On Fri, 21 Mar 2003, Praveen Rajendran wrote: > >>The node requirements draft has some requirements which "MAY" be supported. >>However in the absence of some rigidity ( MUST or SHOULD ) these >>requirements do not convey any information. >> >>A requirement like "IPv6 Jumbograms [RFC2675] MAY be supported." is as good >>as its absence from the draft altogether. >> >>The draft in its introduction says >>"Many IPv6 nodes will implement optional >> or additional features, but all IPv6 nodes can be expected to >> implement the mandatory requirements listed in this document." >> >>Should the draft stick to only those reqirements that are essential and >>steer clear of the others ?? After all it might be tough to capture all >>optional features in the draft. > > > I think it's useful to give a summary of all the relevant specifications, > whether MAY or not. NodeReqs would then be a useful "reading list" for an > implementor. I agree with Pekka. Jari -------------------------------------------------------------------- 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 Mar 21 08:56:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGuQ7f005798; Fri, 21 Mar 2003 08:56:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LGuPrw005797; Fri, 21 Mar 2003 08:56:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LGuL7f005790 for ; Fri, 21 Mar 2003 08:56:22 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2LGuLK16001; Fri, 21 Mar 2003 17:56:21 +0100 (MET) Date: Fri, 21 Mar 2003 17:52:19 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API To: Francis Dupont Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com In-Reply-To: "Your message with ID" <200303202352.h2KNqZof061924@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Some details: > > ..., CGA (cryptographically > generated addresses) and non-CGA addresses etc.. > > => you should note that CGAs are covered by some IPRs. While I'm concerned about IPR and the IPR on CGA, I don't see the benefit of cluttering every document and slide which contains the string "CGA" with text about the IPR. We seem to have been able to talk about RSA for a decade or more without sprinkling text about IPR everywhere the string "RSA" appeared. Is it a hard requirement from the WG that we do this? > It is recommended that the application does a getsockopt() prior > > => this comes only from the uncommon style (one flag from Home, > another one from Care-of, etc). Point taken. Others have commented on this as well. > The following flags are added for the ai_flags in addrinfo data > structure defined in Basic IPv6 Socket API Extension [2]. > > AI_PREFER_SRC_HOME > AI_PREFER_SRC_COA > AI_PREFER_SRC_TMP > AI_PREFER_SRC_PUBLIC > AI_PREFER_SRC_CGA > AI_PREFER_SRC_NONCGA > > => why _SRC_ ? To try to make it clearer that the application can't express this type of preferences for the destination addresses. > 5. IPv4-Mapped IPv6 Addresses > > IPv4-Mapped IPv6 addresses are not supported for setting preference > on home, care-of-address, CGA, non-CGA, public or privacy auto- > configured addresses as source addresses. Because they are all pure > IPv6 addresses. > > => this is not true for home/care-of and this section is not useful. Agreed. > 6. Security Considerations > > It is also recommended that > the applications set IPV6_V6ONLY IP level socket option to permit > the nodes to not process IPv4 packets as IPv4 Mapped addresses. > > => I disagree about the implicit argument that IPv4 Mapped IPv6 > addresses are unsafe. And BTW this has nothing to do in this document. Agreed. > 7. Open Issues > > - Are there more flags we should define at this point in time? > For instance, PREFER_LARGEST_SCOPE? > > => all "matter of taste" rules of address selection which cannot be > controlled through the policy table should be covered here. Do you have a list handy? > - Is there a need for REQUIRE flags in addition to or instead of the > PREFER flags? > > => yes, in some cases it is very important. Any concerns about where and when the failures due to lack of an address satisfying the REQUIREs? > Note that in general it isn't possible to verify > that a requirement can be satisfied until sendto() or connect() > (when the destination address is known) thus this would result > in late errors being reported to the application. > > => this is not really true because an application can use a connect() > to verify the selected source but as I am against any changes in > application I agree with the conclusion. I don't understand what you are suggesting to change in the document with respect to this. Care to elaborate? > - Is there a need for "validation" functions to go with these > preferences such as functions that check whether an address is > a temporary address? > > => it should be useful for some applications to have access to > status of addresses. Ack. 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 Fri Mar 21 09:19:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LHJH7f006016; Fri, 21 Mar 2003 09:19:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LHJHZm006015; Fri, 21 Mar 2003 09:19:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LHJD7f006008 for ; Fri, 21 Mar 2003 09:19:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LHJLcU025385 for ; Fri, 21 Mar 2003 09:19:21 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26907 for ; Fri, 21 Mar 2003 10:19:15 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 17:19:14 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Fri, 21 Mar 2003 17:19:14 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Fri, 21 Mar 2003 17:19:14 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay1.sun.com with ESMTP; Fri, 21 Mar 2003 17:19:13 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2LHJ9v15050; Fri, 21 Mar 2003 18:19:09 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2LHJAof064326; Fri, 21 Mar 2003 18:19:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303211719.h2LHJAof064326@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, Julien.Laganier@Sun.COM, samita@eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Fri, 21 Mar 2003 07:11:35 +0100. Date: Fri, 21 Mar 2003 18:19:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > What I propose is to put the policy in the context of applications > (Unix user structure, environment, etc, even monitors have this kind > of things) so one can tune the address selection before launching > applications. When the context can be managed from applications > (the usual case), this makes [gs]etsockopt() no more necessary. > And global flags can be replaced by default values... Having per-application or per-process overrides of anything if rife with issues since an application isn't a single unit; it consists of several independently developped pieces (libraries being the main source of the many pieces). Thus while the developper know that the pieces s/he has written want to turn the knob to affect the sockets in that piece of code, making the knob be per-process means that it will also affect sockets in libraries. Thus turning the per-process knob can have unknown side effects. Hence the need to have a per-socket knob. => you have access to a per-socket knob when applications can locally tune their context. IMHO to affect sockets in libraries is a good point. For instance usually we'd like to use the local DNS but not always because of views/two heads... What I propose should provide the maximal flexibility. Thanks Francis.Dupont@enst-bretagne.fr PS: it can be implemented with a [gs]etsockopt() and some kind of middleware. So our proposals are not really exclusive. In the case of home/care-of address, my concern from the beginning is that a knob is not enough, we need a smarter rule using the proximity (i.e., prefix matching length) of addresses in order to do the right choice. For instance usually with a destination in a prefix of the visited link, a care-of is better than the home address, and with a destination in the home site, the home address is nearly always better. -------------------------------------------------------------------- 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 Mar 21 09:33:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LHXK7f006337; Fri, 21 Mar 2003 09:33:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LHXKf8006336; Fri, 21 Mar 2003 09:33:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LHXH7f006329 for ; Fri, 21 Mar 2003 09:33:17 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1bur.East.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LHXKuK008223; Fri, 21 Mar 2003 12:33:21 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.8+Sun/8.12.8) with ESMTP id h2LHXJfG027412; Fri, 21 Mar 2003 12:33:19 -0500 (EST) Message-Id: <200303211733.h2LHXJfG027412@strat.East.Sun.COM> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: itojun@iijlab.net cc: Pekka Savola , Francis Dupont , Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM, samita@eng.sun.com From: Sebastien Roy Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-Reply-To: Message from itojun@iijlab.net of "Sat, 22 Mar 2003 01:30:58 +0900." <20030321163058.E2A9F50E7@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Mar 2003 12:33:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net said: > >> I don't understand how can flags to getaddrinfo(3) affect source > >> address selection. where does it take effect in the following code? > >getaddrinfo implementation itself? of course, then libc would have to > >aware of src addresses and such.. > > getaddrinfo(3) does not open socket, so getaddrinfo(3) cannot perform > [gs]etsockopt. This is how I understand the motivation behind these flags: The destination address selection algorithm itself needs to compare each destination with its chosen source address. If the application has input into the source address selection mechanism via the defined socket options, then the application also needs to relay these source address preferences to the destination address ordering algorithm so that it can obtain accurate source address information for each destination. If the destination ordering is implemented in the kernel, then getaddrinfo() will need to pass the application's source address preferences down with the list of destinations so that the algorithm can accurately do its job. It's still unclear to me if all of the newly defined AI_* flags are really needed. Do they each impact the ordering of the addresses in cases that make a difference? For example, there is no destination address ordering rule that takes temporary source addresses into account, so in what case would setting AI_PREFER_SRC_TMP change the order of destinations? -Seb -------------------------------------------------------------------- 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 Mar 21 10:24:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LIOO7f006553; Fri, 21 Mar 2003 10:24:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LIOOFr006552; Fri, 21 Mar 2003 10:24:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LIOL7f006545 for ; Fri, 21 Mar 2003 10:24:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LIOTjO015555 for ; Fri, 21 Mar 2003 10:24:29 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00719 for ; Fri, 21 Mar 2003 10:24:23 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 18:24:22 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP; Fri, 21 Mar 2003 18:24:17 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Fri, 21 Mar 2003 18:24:17 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay2.sun.com with ESMTP; Fri, 21 Mar 2003 18:24:17 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2LIOCv16091; Fri, 21 Mar 2003 19:24:12 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2LIODof064510; Fri, 21 Mar 2003 19:24:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303211824.h2LIODof064510@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, Julien.Laganier@Sun.COM, samita@eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Fri, 21 Mar 2003 17:52:19 +0100. Date: Fri, 21 Mar 2003 19:24:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > The following flags are added for the ai_flags in addrinfo data > structure defined in Basic IPv6 Socket API Extension [2]. > > AI_PREFER_SRC_HOME > AI_PREFER_SRC_COA > AI_PREFER_SRC_TMP > AI_PREFER_SRC_PUBLIC > AI_PREFER_SRC_CGA > AI_PREFER_SRC_NONCGA > > => why _SRC_ ? To try to make it clearer that the application can't express this type of preferences for the destination addresses. => I understand now: you must make this crystal clear in the document! > 7. Open Issues > > - Are there more flags we should define at this point in time? > For instance, PREFER_LARGEST_SCOPE? > > => all "matter of taste" rules of address selection which cannot be > controlled through the policy table should be covered here. Do you have a list handy? => it seems that someone should reread RFC 3484 very carefully. I'll try to do it if I get enough free time... > - Is there a need for REQUIRE flags in addition to or instead of the > PREFER flags? > > => yes, in some cases it is very important. Any concerns about where and when the failures due to lack of an address satisfying the REQUIREs? => EADDRNOTAVAIL on bind(), connect(), sendto(), etc. (i.e., all system calls which directly or indirectly assign a source address). > Note that in general it isn't possible to verify > that a requirement can be satisfied until sendto() or connect() > (when the destination address is known) thus this would result > in late errors being reported to the application. > > => this is not really true because an application can use a connect() > to verify the selected source but as I am against any changes in > application I agree with the conclusion. I don't understand what you are suggesting to change in the document with respect to this. Care to elaborate? => I disagree only about the rationale, so I propose to remove the statement which begins by "Note". Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 21 11:02:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LJ2L7f007013; Fri, 21 Mar 2003 11:02:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LJ2L4W007012; Fri, 21 Mar 2003 11:02:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LJ2H7f007002 for ; Fri, 21 Mar 2003 11:02:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2LJ2OcU004147 for ; Fri, 21 Mar 2003 11:02:24 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09910 for ; Fri, 21 Mar 2003 12:02:15 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 21 Mar 2003 19:02:15 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Fri, 21 Mar 2003 19:02:08 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Fri, 21 Mar 2003 19:02:07 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay12.sun.com with ESMTP; Fri, 21 Mar 2003 19:02:06 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2LJ1xv16409; Fri, 21 Mar 2003 20:01:59 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2LJ1xof064609; Fri, 21 Mar 2003 20:01:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303211901.h2LJ1xof064609@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Julien Laganier cc: Erik Nordmark , Samita Chakrabarti , ipng@sunroof.eng.sun.com, samita@eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Fri, 21 Mar 2003 19:28:14 +0100. <200303211928.14531.julien.laganier@sun.com> Date: Fri, 21 Mar 2003 20:01:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: BTW, I am a bit concerned about applications that need to modify their own context. How do you handle the case of an application which have several threads of execution trying to modify a single context in a contradictory way (e.g. TMP vs PUB, etc.) ? => this is an implementation problem: there are a lot of possible solutions: use a lock, use a context per thread, etc. Thanks Francis.Dupont@enst-bretagne.fr PS: about RFC 3484 tuning : - the policy table (I use it for global tuning on KAME: it works well) - SR2: lower/greater scope (already noticed but not yet in the document) - SR4: home/care-of (already in the document) - SR5: outgoing interface (already noticed, not yet in the document, no proposed wording?) - SR7: temporary/public (already in the document) - SR8: longest matching prefix (IMHO it is covered by the policy table) - DR4: indirect home/care-of - DR7: native/tunnel (something is needed here, perhaps through the interface stuff, aka SR5) - DR8: lower/greater scope (same than SR2) - DR9: longest matching prefix (same than SR8) There is no equivalent in destination rules to SR7, so AI_XXXX_TMP & co are useless (this is in fact obvious :-). I remember there are concerns about the longest matching prefix on more than 64 bits, perhaps we need something here too, even I don't like the idea to fix/extend the RFC 3484 by an API (cf CGAs :-). -------------------------------------------------------------------- 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 Mar 21 14:26:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LMQj7f008855; Fri, 21 Mar 2003 14:26:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LMQj7L008854; Fri, 21 Mar 2003 14:26:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LMQf7f008847 for ; Fri, 21 Mar 2003 14:26:41 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8p2+Sun/8.12.8) with SMTP id h2LMQlAq641177; Fri, 21 Mar 2003 14:26:47 -0800 (PST) Message-Id: <200303212226.h2LMQlAq641177@jurassic.eng.sun.com> Date: Fri, 21 Mar 2003 14:27:07 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API To: Sebastien.Roy@Sun.COM, itojun@iijlab.net Cc: Francis.Dupont@enst-bretagne.fr, Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM, erik.nordmark@Sun.COM, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: P4lhqDh6sTax06A975/pnA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > itojun@iijlab.net said: > > >> I don't understand how can flags to getaddrinfo(3) affect source > > >> address selection. where does it take effect in the following code? > > >getaddrinfo implementation itself? of course, then libc would have to > > >aware of src addresses and such.. > > > > getaddrinfo(3) does not open socket, so getaddrinfo(3) cannot perform > > [gs]etsockopt. > > This is how I understand the motivation behind these flags: > > The destination address selection algorithm itself needs to compare each > destination with its chosen source address. If the application has > input into the source address selection mechanism via the defined socket > options, then the application also needs to relay these source address > preferences to the destination address ordering algorithm so that it can > obtain accurate source address information for each destination. The draft tries to explain the reason of extension of AI_PREFER_SRC* flags in section 4. But it looks like it needs more clarification. The idea actually came from the "Implementation Considerations" section of RFC3484 where it explains that two ways getaddrinfo() can sort the destination addresses before passing them to the apps -- 1) by passing the dest addr to network layer or kernel and have it sort the destination addresses on the basis of source addresses available 2) by retrieving the source address information from the network layer and then sort the destination address list based on the knowledge of source addresses. So, in this case, I can think of an example: a node has configured a TMP address and as well as PUBLIC address on it's interfaces, now the application does setsockopt() to use TMP address as source address, but if it does *not* set the AI_PREFER_SRC_TMP flag in the getaddrinfo() call, getaddrinfo() will return dest-addr corresponding to srcaddr with PUB, TMP order (following RFC3484 rules). Hence it was felt that having additional flags in the addrinfo would be useful for getaddrinfo() to make it's behavior compatible with the altered source address selection . > > If the destination ordering is implemented in the kernel, then > getaddrinfo() will need to pass the application's source address > preferences down with the list of destinations so that the algorithm can > accurately do its job. > > It's still unclear to me if all of the newly defined AI_* flags are > really needed. Do they each impact the ordering of the addresses in > cases that make a difference? For example, there is no destination > address ordering rule that takes temporary source addresses into > account, so in what case would setting AI_PREFER_SRC_TMP change the > order of destinations? It's a good point. There is no specific rule for prefering public over temporary in the destination address selection rule. But there is a rule for source address selection on public vs temporary. So, it implies that if getaddrinfo() may want to sort destination addresses keeping the source address ordering in mind. Thus if there are different destination addresses available corresponding to PUB, TMP src addresses, then AI_PREFER_SRC flags would be useful in that case. Similarly for Mobile IP usage case, the default destination addr is home-addr, but if a MN wants to initiate a connection with another MN in foreign network it can do so by prefering the COA address as source address and setting AI_PREFER_SRC_COA flag in getaddrinfo() to return the destination address in COA, HOA order. Same rule applies for CGA and non-CGA cases. -Samita -------------------------------------------------------------------- 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 Mar 21 15:40:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LNej7f009151; Fri, 21 Mar 2003 15:40:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2LNejwu009150; Fri, 21 Mar 2003 15:40:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2LNee7f009143 for ; Fri, 21 Mar 2003 15:40:40 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8p2+Sun/8.12.8) with SMTP id h2LNelAq663096; Fri, 21 Mar 2003 15:40:47 -0800 (PST) Message-Id: <200303212340.h2LNelAq663096@jurassic.eng.sun.com> Date: Fri, 21 Mar 2003 15:41:07 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: Draft on IPv6 source address selection socket API To: dthaler@windows.microsoft.com Cc: Samita.Chakrabarti@eng.sun.com, ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: wGG8zkm4pQSt90kggCgLFA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Section 4 > > The above flags are ignored for the AF_INET address family. If a > > returned address is an IPv4 address (either as AF_INET6 when > > AI_V4MAPPED, or as AF_INET) then the source preference flags have > > no effect. > > If someone implements Mobile IPv4, wouldn't the HOME/COA flags > be applicable to IPv4 source addresses? Others also commented on V4MAPPED addresses. Are you asking whether a Mobile IPv6 stack node would be communicating a MobileIPv4 node ? Currently there is no such transition mechanism for that and I think, perhaps it's simpler if MIPv4 nodes talks to only MIPv4 mobile nodes. But, are you thinking of the case when a dual stack MIPv4 mobile node wants to use AF_INET6 sockets ? Since this API draft is to support address selection RFC, I'd say it's safe to ignore the flags for at least AF_INET socket family. > > Section 7: > > Is there a need for REQUIRE flags in addition to or instead of the > > PREFER flags? Note that in general it isn't possible to verify > > that a requirement can be satisfied until sendto() or connect() > > (when the destination address is known) thus this would result > > in late errors being reported to the application. > > I agree "require" flags would be nice. For example, if an app requires > a particular type of address and there are no such addresses available, > it may be better to fail the setsockopt than either failing all sends or > using another type of address instead. > > If the consensus is go this way, it would be better in my opinion, > to split the socket option into 3 separate options (HOME/COA, > TMP/PUBLIC, and CGA/NONCGA). For each of those three options, > you'd have 5 values: > Require A > Prefer A > Use system default rules > Prefer B > Require B > ai_flags is type int. So one of the concerns is in the limitation of flag bits (assuming there would be atleast 4 flags required for each option above to map into AI* flags). But, if we need to take the scope and require flags into account, perhaps we have to think about the usage of AI_* flags and its scalability. > I also saw a couple of typos/grammar issues which I will just send > to the authors. Got them. Thanks. -Samita -------------------------------------------------------------------- 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 Mar 21 16:29:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2M0TL7f009374; Fri, 21 Mar 2003 16:29:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2M0TLdJ009373; Fri, 21 Mar 2003 16:29:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2M0TG7f009366 for ; Fri, 21 Mar 2003 16:29:16 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8p2+Sun/8.12.8) with SMTP id h2M0TNAq675300; Fri, 21 Mar 2003 16:29:23 -0800 (PST) Message-Id: <200303220029.h2M0TNAq675300@jurassic.eng.sun.com> Date: Fri, 21 Mar 2003 16:29:43 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API To: Francis.Dupont@enst-bretagne.fr Cc: Julien.Laganier@Sun.COM, Erik.Nordmark@Sun.COM, Samita.Chakrabarti@eng.sun.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hlXEI6wWXTI5nFZgbbFjYg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > context. How do you handle the case of an application which have several > threads of execution trying to modify a single context in a > contradictory way (e.g. TMP vs PUB, etc.) ? > > => this is an implementation problem: there are a lot of possible > solutions: use a lock, use a context per thread, etc. > As Erik explained before, having per-socket knob provides better control on the implementation pieces and it can also satisfy per process behavior. > PS: about RFC 3484 tuning : > - the policy table (I use it for global tuning on KAME: it works well) > - SR2: lower/greater scope (already noticed but not yet in the document) > - SR4: home/care-of (already in the document) > - SR5: outgoing interface (already noticed, not yet in the document, > no proposed wording?) > - SR7: temporary/public (already in the document) > - SR8: longest matching prefix (IMHO it is covered by the policy table) > - DR4: indirect home/care-of > - DR7: native/tunnel (something is needed here, perhaps through > the interface stuff, aka SR5) > - DR8: lower/greater scope (same than SR2) > - DR9: longest matching prefix (same than SR8) This is quite useful! Thanks a lot for the details. > There is no equivalent in destination rules to SR7, so AI_XXXX_TMP & co > are useless (this is in fact obvious :-). Yes, SR7 does not have a corresponding DR?. But getaddrinfo() is supposed to sort the destination addresses keeping source address selection rules (in this case, its SR7) in mind. Hence the AI_PREFER_SRC_* flags make sense for TMP and PUBLIC. > I remember there are concerns about the longest matching prefix on > more than 64 bits, perhaps we need something here too, even I don't > like the idea to fix/extend the RFC 3484 by an API (cf CGAs :-). Does anyone else have any comments on this item ? Thanks, -Samita -------------------------------------------------------------------- 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 Mar 22 08:12:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2MGCn7f010979; Sat, 22 Mar 2003 08:12:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2MGCmMt010978; Sat, 22 Mar 2003 08:12:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2MGCj7f010971 for ; Sat, 22 Mar 2003 08:12:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2MGCqjO022710 for ; Sat, 22 Mar 2003 08:12:52 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27650 for ; Sat, 22 Mar 2003 09:12:46 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:12:46 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:12:45 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:12:45 Z Received: from laptop2.kurtis.autonomica.se ([195.43.225.70] [195.43.225.70]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:12:44 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2MGDqKW009418; Sat, 22 Mar 2003 17:13:59 +0100 (CET) Date: Sat, 22 Mar 2003 01:38:49 +0100 Subject: Re: Nodes Requirements Input Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD2E@tayexc13.americas.cpqcorp.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Has Multi6 done anything that we we can reference? > > Nope. Just heads up. It hopefully will be transparent. Going back through my mail box I tried to find the mail pointing out what it was that Jim wanted from multi6 but I can't find it. Could you elaborate? Or do you want to take it to the multi6 list? - kurtis - -------------------------------------------------------------------- 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 Mar 22 08:14:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2MGEK7f010989; Sat, 22 Mar 2003 08:14:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2MGEKSv010988; Sat, 22 Mar 2003 08:14:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2MGEG7f010981 for ; Sat, 22 Mar 2003 08:14:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2MGEJjO022882 for ; Sat, 22 Mar 2003 08:14:23 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29714 for ; Sat, 22 Mar 2003 09:14:15 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:14:14 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:14:14 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:14:14 Z Received: from laptop2.kurtis.autonomica.se ([195.43.225.70] [195.43.225.70]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 16:14:13 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2MGFWKW009444; Sat, 22 Mar 2003 17:15:34 +0100 (CET) Date: Sat, 22 Mar 2003 05:24:14 +0100 Subject: Re: Mobility in Nodes Requirements Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: john.loughney@nokia.com, Jim.Bound@hp.com, ipng@sunroof.eng.sun.com To: Jari Arkko From: Kurt Erik Lindqvist In-Reply-To: <3E78A92B.7060007@kolumbus.fi> Message-Id: <23599F4D-5C1E-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jim may have a point here about the server in a helicopter. But where > do we draw the limit? How do we know that 3000 kg IBM mainframe > isn't being flown around in a cargo aircraft? Also, the type of > the interface on the device may have significance. Or the application; > a sensor reporting its findings using a single packet would not > need mobility. I have the feeling that are trying to match a solution to a number of problems, rather than to match a number of problems to a solution. Mobility will give you <...>, and problems that match this can use this approach. Problems that do not needs to come up with something else. Is the space shuttle a mobile node? - kurtis - -------------------------------------------------------------------- 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 Mar 22 13:43:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2MLho7f012087; Sat, 22 Mar 2003 13:43:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2MLho1M012086; Sat, 22 Mar 2003 13:43:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2MLhk7f012079 for ; Sat, 22 Mar 2003 13:43:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2MLhsjO014621 for ; Sat, 22 Mar 2003 13:43:54 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16017 for ; Sat, 22 Mar 2003 14:43:48 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 22 Mar 2003 21:43:48 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Sat, 22 Mar 2003 21:43:48 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Sat, 22 Mar 2003 21:43:47 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay12.sun.com with ESMTP; Sat, 22 Mar 2003 21:43:47 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2MLeWv26418; Sat, 22 Mar 2003 22:40:32 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2MLeWof069504; Sat, 22 Mar 2003 22:40:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303222140.h2MLeWof069504@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: Julien.Laganier@Sun.COM, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Fri, 21 Mar 2003 16:29:43 PST. <200303220029.h2M0TNAq675300@jurassic.eng.sun.com> Date: Sat, 22 Mar 2003 22:40:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As Erik explained before, having per-socket knob provides better control on the implementation pieces => no, it gives the same kind of control, and only in modified pieces of code. and it can also satisfy per process behavior. => this is not true: I don't want to patch and recompile all applications. My concern is you provide a device then look for its usage, I prefer to get requirements and only after look for ways to satify them. > There is no equivalent in destination rules to SR7, so AI_XXXX_TMP & co > are useless (this is in fact obvious :-). Yes, SR7 does not have a corresponding DR?. But getaddrinfo() is supposed to sort the destination addresses keeping source address selection rules (in this case, its SR7) in mind. Hence the AI_PREFER_SRC_* flags make sense for TMP and PUBLIC. => if there are for each prefix a TMP and a PUBLIC addresses AI_PREFER_SRC_TMP & co are strictly useless so are candidate for a garbage collection when we'll run out of bits in ai_flag... Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 22 21:06:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2N56r7f013114; Sat, 22 Mar 2003 21:06:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2N56rSQ013113; Sat, 22 Mar 2003 21:06:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2N56o7f013106 for ; Sat, 22 Mar 2003 21:06:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2N56qcU019662 for ; Sat, 22 Mar 2003 21:06:52 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA23459 for ; Sat, 22 Mar 2003 22:06:46 -0700 (MST) From: john.loughney@nokia.com Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 05:06:44 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 05:05:22 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 05:05:22 Z Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 05:05:20 Z Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2N53pM28849 for ; Sun, 23 Mar 2003 07:03:51 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 23 Mar 2003 07:05:17 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 07:05:17 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 23 Mar 2003 07:05:15 +0200 Subject: RE: Mobility in Nodes Requirements Date: Sun, 23 Mar 2003 07:05:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: X-MS-Has-Attach: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLvipndc3BkiEUTQiO51Uj133C1WgBbv/3w To: Cc: X-OriginalArrivalTime: 23 Mar 2003 05:05:15.0875 (UTC) FILETIME=[CABDBB30:01C2F0F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2N56o7f013107 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Praveen, > Should the draft stick to only those reqirements that are > essential and steer clear of the others ?? After all it might be > tough to capture all optional features in the draft. I think that the draft should capture most all of the basic IPv6 RFCs at the level needed. For some, sub-requirements may need to be explicitly called out, while for others, simple level of support needed may be enough. John -------------------------------------------------------------------- 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 Mar 23 02:13:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NADQ7f013954; Sun, 23 Mar 2003 02:13:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2NADPxw013953; Sun, 23 Mar 2003 02:13:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NADL7f013946 for ; Sun, 23 Mar 2003 02:13:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2NADScU006258 for ; Sun, 23 Mar 2003 02:13:28 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18239 for ; Sun, 23 Mar 2003 03:13:21 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:13:19 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:13:18 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:13:17 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:13:15 Z Received: from localhost (unknown [3ffe:501:4819:2000:28a6:eb6f:6041:b6dd]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 89BD115210; Sun, 23 Mar 2003 19:13:42 +0900 (JST) Date: Sun, 23 Mar 2003 19:13:43 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-Reply-To: <200303202339.h2KNdCof061873@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200303202339.h2KNdCof061873@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 21 Mar 2003 00:39:12 +0100, >>>>> Francis Dupont said: > A draft has been submitted to address source address selection at > the per-socket (and per apps) basis. Currently it discusses preferences > of source address selection by the application for privacy addresses, > mobileipv6 addresses and Cryptographically generated addresses. > Thus the application can reverse the sense of default source address > selection by using the proposed APIs. > => I have a major concern about the style of the API: it is at the > socket level ([gs]etsockopt()) when it should be in the context of > applications: > - nobody wants to modify every applications in order to use the API > (an unfortunately many applications can want to toggle one of the > address selection knobs) > - at the opposite a global knob is not flexible again. I tend to agree, but do you have any concrete and feasible suggestion to implement this? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 23 02:33:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NAXC7f014151; Sun, 23 Mar 2003 02:33:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2NAXCH8014150; Sun, 23 Mar 2003 02:33:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NAX77f014143 for ; Sun, 23 Mar 2003 02:33:07 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2NAXFcU009229 for ; Sun, 23 Mar 2003 02:33:15 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12844 for ; Sun, 23 Mar 2003 02:33:09 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:32:28 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:32:22 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:32:22 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 10:32:19 Z Received: from localhost (unknown [3ffe:501:4819:2000:28a6:eb6f:6041:b6dd]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 003F115210; Sun, 23 Mar 2003 19:32:20 +0900 (JST) Date: Sun, 23 Mar 2003 19:32:22 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@Sun.COM, Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM Cc: ipng@sunroof.eng.sun.com Subject: comments on the address selection API draft User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 63 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have some comments on draft-chakrabarti-ipv6-addrselect-api-00.txt, in addition to those already raised in this list (I'd apologize in advance if there's any duplication). 1. Introduction Currently IPv6 socket API extensions does not provide a mechanism to choose a particular source address other than simple bind() operation. This is not really true. We can also specify the source address by the IPV6_PKTINFO socket option or ancillary data item defined the advanced API. This does not matter much, though, because we still need to specify a particular source address. Furthermore, the approach is to define two flags for each purpose, so that an application can specify either that it prefers 'X' or prefers 'not X', or it can choose not to set either of the flags relating to 'X' and leave it up to the system default, perhaps while specifing its preferences for some other attribute of the source addresses. Hmm, I'm not sure if this is really possible with the API described... later the draft says (in Section 3): The flags defined in this document are: IPV6_PREFER_SRC_HOME IPV6_PREFER_SRC_COA IPV6_PREFER_SRC_TMP IPV6_PREFER_SRC_PUBLIC IPV6_PREFER_SRC_CGA IPV6_PREFER_SRC_NONCGA (...) .... If the option is not set, the system selects a default value. Setting conflicting flags at the same time results in the error EINVAL. I read this to mean unless IPV6_SRC_PREFERENCES is explicitly specified, the kernel will choose the default values for all the parameters. If my understanding is correct, how can I specify a preference for HOME vs COA but keep the default for TMP vs PUBLIC? Am I supposed to unset both IPV6_PREFER_SRC_TMP and IPV6_PREFER_SRC_PUBLIC? But isn't it a conflicting configuration since these two are exclusive flags? The current specification is at least unclear to me on this, and perhaps even contradicts itself. We could clarify this point, but I'm afraid the result would be complicated and unintuitive... 5. IPv4-Mapped IPv6 Addresses IPv4-Mapped IPv6 addresses are not supported for setting preference on home, care-of-address, CGA, non-CGA, public or privacy auto- configured addresses as source addresses. "privacy auto-configured addresses" should just be "temporary addresses" to be consistent with the rest of this draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 23 12:35:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NKZ27f015522; Sun, 23 Mar 2003 12:35:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2NKZ160015521; Sun, 23 Mar 2003 12:35:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NKYw7f015514 for ; Sun, 23 Mar 2003 12:34:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2NKZ7cU028813 for ; Sun, 23 Mar 2003 12:35:07 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10419 for ; Sun, 23 Mar 2003 13:35:01 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 20:35:01 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 20:35:00 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 20:35:00 Z Received: from micaiah.rwc.iqcicom.com ([66.135.128.69] [66.135.128.69]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 20:34:59 Z Received: from iqmail.net (unverified [66.135.128.69]) by micaiah.rwc.iqcicom.com (Vircom SMTPRS 2.0.244) with ESMTP id ; Sun, 23 Mar 2003 12:29:39 -0800 Message-Id: <428770ac5e7647c5a7d4ab3717bd9900.kuntal@iqmail.net> X-EM-APIVersion: 2, 0, 1, 0 X-Priority: 3 (Normal) From: "" To: itojun@iijlab.net CC: ipng@sunroof.eng.sun.com Subject: Re: Re: DAD in node requirements draft Date: Sun, 23 Mar 2003 12:29:39 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2NKYw7f015515 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > for link-local address RFC2472 exception makes sense, but for others > it does not. i'd say keep node-req text as is. > > itojun Hmm.. OK, let's see what RFC2472 has to say about this: " As long as the Interface Identifier is negotiated in the IPV6CP phase of the PPP connection setup, it is redundant to perform duplicate address detection as a part of the IPv6 Stateless Autoconfiguration protocol [3]. Therefore it is recommended that for PPP links with the IPV6CP Interface-Identifier option enabled the default value of the DupAddrDetectTransmits autoconfiguration variable [3] be zero. " And what RFC2462 has to say: " For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. In the case of addresses created through stateless autoconfig, however, the uniqueness of an address is determined primarily by the portion of the address formed from an interface identifier. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface identifier need not be tested individually " In a PPP link the host autoconfigures the addresses (link/global) based on IID and Prefix configured/advertised by the AR. If the AR does not add IID config option in IPv6CP, the host can use it's unique link-layer ID if required (note that otherwise autoconfiguration stops). Besides the AR and the host there is no one on the link. Therefore running DAD (NS/NA) for any autoconfigured address (including autoconfigured global) is redundant for the point-to-point link, IMHO. Please explain why running DAD for an autoconfigured non-link local address based on IID received from IPv6CP and prefix received from RA makes sense to you. Regards, Kuntal -------------------------------------------------------------------- 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 Mar 23 13:48:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NLmO7f016081; Sun, 23 Mar 2003 13:48:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2NLmO72016080; Sun, 23 Mar 2003 13:48:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NLmL7f016073 for ; Sun, 23 Mar 2003 13:48:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2NLmTcU008452 for ; Sun, 23 Mar 2003 13:48:29 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23735 for ; Sun, 23 Mar 2003 14:48:24 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 23 Mar 2003 21:48:23 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP; Sun, 23 Mar 2003 21:46:59 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP; Sun, 23 Mar 2003 21:46:59 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay12.sun.com with ESMTP; Sun, 23 Mar 2003 21:46:59 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2NLkqv08925; Sun, 23 Mar 2003 22:46:52 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2NLkpof071745; Sun, 23 Mar 2003 22:46:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303232146.h2NLkpof071745@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Samita Chakrabarti , ipng@sunroof.eng.sun.com, erik.nordmark@Sun.COM, Julien.Laganier@Sun.COM Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Sun, 23 Mar 2003 19:13:43 +0900. Date: Sun, 23 Mar 2003 22:46:51 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Fri, 21 Mar 2003 00:39:12 +0100, >>>>> Francis Dupont said: > A draft has been submitted to address source address selection at > the per-socket (and per apps) basis. Currently it discusses preferences > of source address selection by the application for privacy addresses, > mobileipv6 addresses and Cryptographically generated addresses. > Thus the application can reverse the sense of default source address > selection by using the proposed APIs. > => I have a major concern about the style of the API: it is at the > socket level ([gs]etsockopt()) when it should be in the context of > applications: > - nobody wants to modify every applications in order to use the API > (an unfortunately many applications can want to toggle one of the > address selection knobs) > - at the opposite a global knob is not flexible again. I tend to agree, but do you have any concrete and feasible suggestion to implement this? => in an UNIX context, I can split the question into three parts: where to put the information, how to manage it, how to use it. For the place, there are two big options: - in user or proc structure, i.e., somewhere in the state of the process, exactly like user credentials with possible sharing, etc. - in environment variables, i.e., like RES_OPTIONS for tuning of the resolver library via the process context. In the second case, the obvious managing functions are [gs]etenv() but this makes a textual form of tuning tables and knobs necessary. In the first case, the best is to add a sysctl() like you already did for the policy table. An inheritance rule completes this part. There are two main ways to use the information: inside the kernel (like the policy table or the proposed [gs]etsockopt()) or inside the standard library (like the current resolver tuning). Try first with the policy table (because you have already a good support for a global one and because it is the main way to tune address selection, i.e., I already use it on some multi-homed nodes and there are some cases where I'd like to have a per-application policy). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 23 15:50:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NNo67f016509; Sun, 23 Mar 2003 15:50:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2NNo5rU016508; Sun, 23 Mar 2003 15:50:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2NNo17f016501 for ; Sun, 23 Mar 2003 15:50:01 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8p2+Sun/8.12.8) with SMTP id h2NNo9Aq951857; Sun, 23 Mar 2003 15:50:10 -0800 (PST) Message-Id: <200303232350.h2NNo9Aq951857@jurassic.eng.sun.com> Date: Sun, 23 Mar 2003 15:50:30 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: comments on the address selection API draft To: jinmei@isl.rdc.toshiba.co Cc: erik.nordmark@Sun.COM, Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0gp0Xev++16ky7RX5dMdpA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. Introduction > > Currently IPv6 socket API extensions does not provide a > mechanism to choose a particular source address other than simple > bind() operation. > > This is not really true. We can also specify the source address by > the IPV6_PKTINFO socket option or ancillary data item defined the > advanced API. This does not matter much, though, because we still > need to specify a particular source address. > Point noted. The text in the draft was written in the context of basic socket api in mind, hence it only refers to bind(). > Furthermore, the approach is to define two flags for each purpose, > so that an application can specify either that it prefers 'X' or > prefers 'not X', or it can choose not to set either of the flags > relating to 'X' and leave it up to the system default, perhaps while > specifing its preferences for some other attribute of the source > addresses. > > Hmm, I'm not sure if this is really possible with the API described... > later the draft says (in Section 3): > Please see the comment below. > The flags defined in this document are: > > IPV6_PREFER_SRC_HOME > IPV6_PREFER_SRC_COA > IPV6_PREFER_SRC_TMP > IPV6_PREFER_SRC_PUBLIC > IPV6_PREFER_SRC_CGA > IPV6_PREFER_SRC_NONCGA > (...) > .... If the option is not set, the system selects > a default value. Setting conflicting flags at the same time results > in the error EINVAL. > > I read this to mean unless IPV6_SRC_PREFERENCES is explicitly > specified, the kernel will choose the default values for all the > parameters. If IPV6_SRC_PREFERENCES is not specified then the source addresses are chosen by the system. Assuming that the system implements RFC3484 (default addr selection ), it will choose the appropriate source address as per address selection rules. Intent of this draft is to alter the knob of source address selection from the system level to per socket level. > If my understanding is correct, how can I specify a > preference for HOME vs COA but keep the default for TMP vs PUBLIC? Not sure exactly what you are looking for, but I try to explain here. It only applies to a per-socket basis. So, while one socket in an app sets its SRC preference to COA and sends outgoing packet with srcaddr=COA, other socket in same or different application can choose to setsockopt(s, IPV6_SRC_PREFERNCE, &flags, ...) where flag indicates IPV6_PREFER_SRC_TMP and packets sent through that socket use TMP addr as source address. At the sametime, a third application which does not set IPV6_SRC_PREFERNCES, sends packet with a source address determined by the kernel by following generic systemwide source address selection rules. Thus there is no concept of default parameter value of each type of addresses here, by 'default' , the draft means the value chosen by the kernel. We can clarify that if that is not quite clear in the draft. > Am I supposed to unset both IPV6_PREFER_SRC_TMP and > IPV6_PREFER_SRC_PUBLIC? But isn't it a conflicting configuration > since these two are exclusive flags? > No. one does not need to unset all other flags in order to set one specific flag. But, I suppose (not specified yet) one can set a combination of flags if it makes sense (i,e. IPV6_PREFER_SRC_PUBLIC| IPV6_PREFER_SRC_COA), if the COA has both temporary and public addresses. Although, it does not make too much sense to me, other than it makes things complex; but it is an implementation option. > The current specification is at least unclear to me on this, and > perhaps even contradicts itself. We could clarify this point, but I'm > afraid the result would be complicated and unintuitive... > > 5. IPv4-Mapped IPv6 Addresses > > IPv4-Mapped IPv6 addresses are not supported for setting preference > on home, care-of-address, CGA, non-CGA, public or privacy auto- > configured addresses as source addresses. > > "privacy auto-configured addresses" should just be "temporary > addresses" to be consistent with the rest of this draft. Ok. There has been some comments on the list about restriction on supporting IPv4-mapped addresses. Thanks for your comments. -Samita -------------------------------------------------------------------- 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 Mar 23 18:25:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O2Pq7f017101; Sun, 23 Mar 2003 18:25:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2O2PqJX017100; Sun, 23 Mar 2003 18:25:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O2Pm7f017091 for ; Sun, 23 Mar 2003 18:25:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2O2PvcU020945 for ; Sun, 23 Mar 2003 18:25:57 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25839 for ; Sun, 23 Mar 2003 19:25:52 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 02:25:51 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 01:27:34 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 01:27:34 Z Received: from ALPHA9.ITS.MONASH.EDU.AU (ALPHA9.ITS.MONASH.EDU.AU [130.194.1.9]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 01:27:33 Z Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KTWI1DZ4IW9BX4KI@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 12:20:01 +1100 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 4721920005; Mon, 24 Mar 2003 12:20:01 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 2F1F720004; Mon, 24 Mar 2003 12:20:01 +1100 (EST) Date: Mon, 24 Mar 2003 12:20:01 +1100 From: Greg Daley Subject: Re: avoiding NAT with IPv6 To: Quality Quorum Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@ENG.MONASH.EDU.AU Message-Id: <3E7E5D41.1070201@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Aleksey, I'm giving this one last attempt. Quality Quorum wrote: > > On Fri, 21 Mar 2003, Greg Daley wrote: > > >>I'm pretty sure this would cripple any (reasonable) >>end-to-end assumptions people may want to make with >>programming IPv6 apps. > > > I do not think so. Well, have you ever seen the hoops required for a NAT to undertake H.323 or another peer to peer application with multiple channels? NAT only works relatively easily with single session client apps. P-to-P applications are a candidate NextBigThing. Of course, we can't support NAT modifications for every application which will be programmed, so devices on NAT'ed networks will not be able to participate in p-to-p. IPv4 networks are rife with NAT, so IPv6 adoption may be driven by p-to-p. If NAT is good enough, there is currently no significant reason to go to IPv6. > >>Please, think of your children when asking us to >>support NAT. We're trying to make the Internet a system which >>will support the applications we need in 2020, not 1999. > > > If you are making assumptions that there will be no NAT6, but > it may be forced on us by the market, it is you who are > crippling the Internet of the future. > Actually, I'm not. I'm asking that all efforts toward NAT6 be dropped until there is interest from the user community. We know how NAT4 works, NAT6 will be trivial. In the mean time we'll try to wean people off NAT, by providing better applications and connectivity with end-to-end IPv6. >>I'm not advocating "fight against the tide", but >>initially IPv6 can be marketed as better than IPv4 >>because of NAT4. Once IPv6 starts taking off, then >>it's our job to educate people about NAT being evil. > > > If you are successful there will be no NAT6 even it if > it is supported, however if you are unsuccessful the damage > done by the no-NAT6 decision will be significant. There is no damage to be done. We've got almost 2^61 networks to give away, and almost 2^45 organizations to give addresses to. It will be at least 3 years before there are 2^45 people in the world :) NAT can come in if we get to the point when we've used up 2^44 organizational allocations and have 2^44 left. I'd suggest that by that time we'd be able to go to the next IPng though. >>We shouldn't be accomodating it now. > > > Your own argument points the other way - if we are thinking > about future we should not artificially cripple the > environment now. End-to-end will never cripple NAT. NAT can ALWAYS be retrofitted to an end-to-end network (maybe some applications won't work, but we know ones that will). If there's need, we can do it simply. Running end-to-end applications on a NAT network is a nightmare, though. Why don't we wait for the problem to arise before we implement NAT? It's not like we don't have better things to do. Greg -------------------------------------------------------------------- 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 Mar 23 22:05:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O65e7f018771; Sun, 23 Mar 2003 22:05:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2O65e1t018770; Sun, 23 Mar 2003 22:05:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O65a7f018763 for ; Sun, 23 Mar 2003 22:05:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2O65jcU024312 for ; Sun, 23 Mar 2003 22:05:45 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA14770 for ; Sun, 23 Mar 2003 23:05:35 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 06:05:19 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 06:05:18 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 06:05:18 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 06:05:17 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9D08146E0; Mon, 24 Mar 2003 01:04:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 01:04:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Mobility in Nodes Requirements Date: Mon, 24 Mar 2003 01:04:45 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDCD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLwjhFB6f49oOyMQhCErpi0uScY/gBPPvwA From: "Bound, Jim" To: "Kurt Erik Lindqvist" , "Jari Arkko" Cc: , X-OriginalArrivalTime: 24 Mar 2003 06:04:45.0541 (UTC) FILETIME=[44D74950:01C2F1CB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2O65b7f018764 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is my exact point about this spec. It seems if this will continue without a focus as Kurtis says below and I have stated previously we will need a serious applicability statement. Because it is BCP I am backing off a little as most of the market don't care about our BCPs. But there needs to be applicability statement. /jim >-----Original Message----- >From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] >Sent: Friday, March 21, 2003 11:24 PM >To: Jari Arkko >Cc: john.loughney@nokia.com; Bound, Jim; ipng@sunroof.eng.sun.com >Subject: Re: Mobility in Nodes Requirements > > >> Jim may have a point here about the server in a helicopter. >But where >> do we draw the limit? How do we know that 3000 kg IBM >mainframe isn't >> being flown around in a cargo aircraft? Also, the type of the >> interface on the device may have significance. Or the application; a >> sensor reporting its findings using a single packet would not need >> mobility. > >I have the feeling that are trying to match a solution to a number of >problems, rather than to match a number of problems to a solution. >Mobility will give you <...>, and problems that match this can >use this >approach. Problems that do not needs to come up with something else. > >Is the space shuttle a mobile node? > >- kurtis - > > -------------------------------------------------------------------- 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 Mar 23 22:56:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O6uv7f019016; Sun, 23 Mar 2003 22:56:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2O6uuIV019015; Sun, 23 Mar 2003 22:56:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O6uq7f019008 for ; Sun, 23 Mar 2003 22:56:52 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.8p2+Sun/8.12.8) with SMTP id h2O6v0Aq980322; Sun, 23 Mar 2003 22:57:00 -0800 (PST) Message-Id: <200303240657.h2O6v0Aq980322@jurassic.eng.sun.com> Date: Sun, 23 Mar 2003 22:57:21 -0800 (PST) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API To: Francis.Dupont@enst-bretagne.fr Cc: Julien.Laganier@Sun.COM, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gbmceZkEoBJqf2xDXve7Sg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_24 SunOS 5.10 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > and it can also satisfy per process behavior. > > => this is not true: I don't want to patch and recompile all applications. > My concern is you provide a device then look for its usage, I prefer to > get requirements and only after look for ways to satify them. > I assume these socket options would be applicable more for new type of applications. But I don't see a problem in updating existing application with new socket option and recompile them, if the application wants to serve special cases. For example, it's not surprizing that common network application be modified for running on mobile devices. Also, per-socket control is more desirable than just per-process control, as one application may choose to set different source address for different set of sockets. I don't think threading (as you mentioned before) is a good alternative to that. > > There is no equivalent in destination rules to SR7, so AI_XXXX_TMP & co > > are useless (this is in fact obvious :-). > > Yes, SR7 does not have a corresponding DR?. But getaddrinfo() is supposed > to sort the destination addresses keeping source address selection rules > (in this case, its SR7) in mind. Hence the AI_PREFER_SRC_* flags make sense > for TMP and PUBLIC. > > => if there are for each prefix a TMP and a PUBLIC addresses AI_PREFER_SRC_TMP > & co are strictly useless so are candidate for a garbage collection when > we'll run out of bits in ai_flag... I am not sure I understand your point here. I understand that ai_flag bits are limited. But if there are multiple prefixes with TMP address and AI_PREFER_SRC_TMP is set, TMP addresses will be preferred. I assume that TMP addresses will be sorted among themselves as per other src address selection rules. Thanks, -Samita -------------------------------------------------------------------- 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 Mar 24 01:38:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O9ce7f019545; Mon, 24 Mar 2003 01:38:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2O9cdEW019544; Mon, 24 Mar 2003 01:38:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2O9ca7f019537 for ; Mon, 24 Mar 2003 01:38:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2O9cgHP003309 for ; Mon, 24 Mar 2003 01:38:42 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16307 for ; Mon, 24 Mar 2003 01:38:37 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 09:38:36 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 06:11:17 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 06:14:05 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 06:14:03 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 770332139; Mon, 24 Mar 2003 01:14:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 01:14:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [mobile-ip] Draft on IPv6 source address selection socket API Date: Mon, 24 Mar 2003 01:14:01 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03241077@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Draft on IPv6 source address selection socket API Thread-Index: AcLvyxESENSt2LmVT5evsP3r5H7Q5QCAJTiQ From: "Bound, Jim" To: "Erik Nordmark" , "Francis Dupont" Cc: "Samita Chakrabarti" , , , X-OriginalArrivalTime: 24 Mar 2003 06:14:02.0184 (UTC) FILETIME=[90A04480:01C2F1CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2O9ca7f019538 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, On CGA. It is different now. We face mass deployment of required security worldwide and I hear it all the time now. CGA being a base for our addresses is far different scope of use than RSA mumbo-jumbo et al. The IPR is a real problem and I think a show stopper. There can be no vendor advantage over others with CGA if it is to become pervasive, and questionable for the IETF to pursue this to far without getting some type of resolution. The IETF could be setting a precedent and opening pandora's box and end up sitting in anti-trust problem. Go talk to your IETF ISOC council is my advise if you have not already. It is also not the same type of legal problem as using RSA as an entity. I think labeling it often as IPR issue is prudent in our community. Including not using it because of the IPR. /jim >-----Original Message----- >From: Erik Nordmark [mailto:Erik.Nordmark@Sun.COM] >Sent: Friday, March 21, 2003 11:52 AM >To: Francis Dupont >Cc: Samita Chakrabarti; ipng@sunroof.eng.sun.com; >erik.nordmark@Sun.COM; Julien.Laganier@Sun.COM; samita@eng.sun.com >Subject: Re: [mobile-ip] Draft on IPv6 source address >selection socket API > > >> Some details: >> >> ..., CGA (cryptographically >> generated addresses) and non-CGA addresses etc.. >> >> => you should note that CGAs are covered by some IPRs. > >While I'm concerned about IPR and the IPR on CGA, I don't see >the benefit of cluttering every document and slide which >contains the string "CGA" with text about the IPR. We seem to >have been able to talk about RSA for a decade or more without >sprinkling text about IPR everywhere the string "RSA" >appeared. Is it a hard requirement from the WG that we do this? > >> It is recommended that the application does a getsockopt() >> prior >> >> => this comes only from the uncommon style (one flag from Home, >> another one from Care-of, etc). > >Point taken. Others have commented on this as well. > >> The following flags are added for the ai_flags in >addrinfo data >> structure defined in Basic IPv6 Socket API Extension [2]. >> >> AI_PREFER_SRC_HOME >> AI_PREFER_SRC_COA >> AI_PREFER_SRC_TMP >> AI_PREFER_SRC_PUBLIC >> AI_PREFER_SRC_CGA >> AI_PREFER_SRC_NONCGA >> >> => why _SRC_ ? > >To try to make it clearer that the application can't express >this type of preferences for the destination addresses. > >> 5. IPv4-Mapped IPv6 Addresses >> >> IPv4-Mapped IPv6 addresses are not supported for >setting preference >> on home, care-of-address, CGA, non-CGA, public or privacy auto- >> configured addresses as source addresses. Because they >are all pure >> IPv6 addresses. >> >> => this is not true for home/care-of and this section is not useful. > >Agreed. > >> 6. Security Considerations >> >> It is also recommended that >> the applications set IPV6_V6ONLY IP level socket >option to permit >> the nodes to not process IPv4 packets as IPv4 Mapped addresses. >> >> => I disagree about the implicit argument that IPv4 Mapped IPv6 >> addresses are unsafe. And BTW this has nothing to do in this >document. > >Agreed. > >> 7. Open Issues >> >> - Are there more flags we should define at this point in time? >> For instance, PREFER_LARGEST_SCOPE? >> >> => all "matter of taste" rules of address selection which cannot be >> controlled through the policy table should be covered here. > >Do you have a list handy? > >> - Is there a need for REQUIRE flags in addition to or >instead of the >> PREFER flags? >> >> => yes, in some cases it is very important. > >Any concerns about where and when the failures due to lack of >an address satisfying the REQUIREs? > >> Note that in general it isn't possible to verify >> that a requirement can be satisfied until sendto() >or connect() >> (when the destination address is known) thus this >would result >> in late errors being reported to the application. >> >> => this is not really true because an application can use a >connect() >> to verify the selected source but as I am against any changes in >> application I agree with the conclusion. > >I don't understand what you are suggesting to change in the >document with respect to this. Care to elaborate? > >> - Is there a need for "validation" functions to go with these >> preferences such as functions that check whether an >address is >> a temporary address? >> >> => it should be useful for some applications to have access >to status >> of addresses. > >Ack. > > 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 Mon Mar 24 02:46:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OAk67f019908; Mon, 24 Mar 2003 02:46:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OAk6bP019907; Mon, 24 Mar 2003 02:46:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OAk27f019900 for ; Mon, 24 Mar 2003 02:46:02 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2OAk0K15739; Mon, 24 Mar 2003 11:46:00 +0100 (MET) Date: Mon, 24 Mar 2003 11:42:00 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on the address selection API draft To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: erik.nordmark@Sun.COM, Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This is not really true. We can also specify the source address by > the IPV6_PKTINFO socket option or ancillary data item defined the > advanced API. This does not matter much, though, because we still > need to specify a particular source address. Good point. The issue is that the existing APIs can only support specifying a specific source address, whether bind() or IPV6_PKTINFO is used. We can make this more clear. > I read this to mean unless IPV6_SRC_PREFERENCES is explicitly > specified, the kernel will choose the default values for all the > parameters. If my understanding is correct, how can I specify a > preference for HOME vs COA but keep the default for TMP vs PUBLIC? > Am I supposed to unset both IPV6_PREFER_SRC_TMP and > IPV6_PREFER_SRC_PUBLIC? But isn't it a conflicting configuration > since these two are exclusive flags? If you do a setsockopt with IPV6_PREFER_SRC_HOME (or COA) and do not set either of _TMP or _PUBLIC, then you will leave the TMP vs. PUBLIC selection at the system default. Thus not specifying either of "X" and "not X" leaves the "X" property of the address selection at the system default. > The current specification is at least unclear to me on this, and > perhaps even contradicts itself. We could clarify this point, but I'm > afraid the result would be complicated and unintuitive... The questions on this point makes it clear to me that the document is unclear :-) An alternate API would be to have one flag per property and always require a get before a set. An example of that style of API is fcntl with F_SETFL and F_GETFL where the logic for setting e.g. FASYNC is flags = fcntl(s, F_GETFL, NULL); flags |= FASYNC; fcntl(s, F_SETFL, flags); and the logic for clearing it is: flags = fcntl(s, F_GETFL, NULL); flags &= ~FASYNC; fcntl(s, F_SETFL, flags); Something similar could be done using getsockopt and setsockopt for the source preferences. But this would require a getsockopt before the setsockopt to avoid accidentally changing some preferences. 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 Mar 24 03:14:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OBEB7f020215; Mon, 24 Mar 2003 03:14:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OBEBdW020214; Mon, 24 Mar 2003 03:14:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OBE77f020207 for ; Mon, 24 Mar 2003 03:14:07 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2OBE9K17916; Mon, 24 Mar 2003 12:14:09 +0100 (MET) Date: Mon, 24 Mar 2003 12:10:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [mobile-ip] Draft on IPv6 source address selection socket API To: "Bound, Jim" Cc: Erik Nordmark , Francis Dupont , Samita Chakrabarti , ipng@sunroof.eng.sun.com, Julien.Laganier@Sun.COM, samita@eng.sun.com In-Reply-To: "Your message with ID" <9C422444DE99BC46B3AD3C6EAFC9711B03241077@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On CGA. It is different now. We face mass deployment of required security > worldwide and I hear it all the time now. CGA being a base for our > addresses is far different scope of use than RSA mumbo-jumbo et al. The IPR > is a real problem and I think a show stopper. There can be no vendor > advantage over others with CGA if it is to become pervasive, and > questionable for the IETF to pursue this to far without getting some type of > resolution. The IETF could be setting a precedent and opening pandora's box > and end up sitting in anti-trust problem. Go talk to your IETF ISOC council > is my advise if you have not already. It is also not the same type of legal > problem as using RSA as an entity. > > I think labeling it often as IPR issue is prudent in our community. > Including not using it because of the IPR. I agree with the IPR concerns for CGA. It just feels like overkill to have to attach a "there is IPR" piece of text every time we mention CGA in documents. The documents that specify to how implement CGA (the stuff that is actually covered by the claimed IPR) should have the required notices for sure, but I'm a bit leery of putting it everywhere where CGA is referenced. My concern is that should the IPR situation for CGA change we'll have a dozen documents which potentially contain inaccurate information. But perhaps this isn't a big deal. 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 Mar 24 05:50:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ODoJ7f021068; Mon, 24 Mar 2003 05:50:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2ODoJ6X021067; Mon, 24 Mar 2003 05:50:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2ODoG7f021060 for ; Mon, 24 Mar 2003 05:50:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2ODoNHP009783 for ; Mon, 24 Mar 2003 05:50:23 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26316 for ; Mon, 24 Mar 2003 06:50:17 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 13:50:08 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 13:50:07 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 13:50:07 Z Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 13:50:06 Z Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 551C422B2; Mon, 24 Mar 2003 08:50:05 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 08:50:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [mobile-ip] Draft on IPv6 source address selection socket API Date: Mon, 24 Mar 2003 08:50:04 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDD6@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mobile-ip] Draft on IPv6 source address selection socket API Thread-Index: AcLx9oYx+LMW3DJfQmW9R29YmkcOZQAFbAog From: "Bound, Jim" To: "Erik Nordmark" Cc: "Francis Dupont" , "Samita Chakrabarti" , , , X-OriginalArrivalTime: 24 Mar 2003 13:50:05.0205 (UTC) FILETIME=[4641EC50:01C2F20C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2ODoG7f021061 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agree on the overkill. I agree with you just did not want it to be hidden either. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: Monday, March 24, 2003 6:10 AM > To: Bound, Jim > Cc: Erik Nordmark; Francis Dupont; Samita Chakrabarti; > ipng@sunroof.eng.sun.com; Julien.Laganier@sun.com; samita@eng.sun.com > Subject: RE: [mobile-ip] Draft on IPv6 source address > selection socket API > > > > On CGA. It is different now. We face mass deployment of required > > security worldwide and I hear it all the time now. CGA > being a base > > for our addresses is far different scope of use than RSA > mumbo-jumbo > > et al. The IPR is a real problem and I think a show stopper. There > > can be no vendor advantage over others with CGA if it is to become > > pervasive, and questionable for the IETF to pursue this to > far without > > getting some type of resolution. The IETF could be setting a > > precedent and opening pandora's box and end up sitting in > anti-trust > > problem. Go talk to your IETF ISOC council is my advise if you have > > not already. It is also not the same type of legal problem > as using > > RSA as an entity. > > > > I think labeling it often as IPR issue is prudent in our community. > > Including not using it because of the IPR. > > I agree with the IPR concerns for CGA. > It just feels like overkill to have to attach a "there is > IPR" piece of text every time we mention CGA in documents. > The documents that specify to how implement CGA (the stuff > that is actually covered by the claimed IPR) should have the > required notices for sure, but I'm a bit leery of putting it > everywhere where CGA is referenced. My concern is that should > the IPR situation for CGA change we'll have a dozen documents > which potentially contain inaccurate information. But perhaps > this isn't a big deal. > > 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 Mar 24 06:29:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OETZ7f021330; Mon, 24 Mar 2003 06:29:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OETZOH021329; Mon, 24 Mar 2003 06:29:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OETW7f021322 for ; Mon, 24 Mar 2003 06:29:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OETdHP016053 for ; Mon, 24 Mar 2003 06:29:39 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13780 for ; Mon, 24 Mar 2003 06:29:32 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:22:51 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:22:39 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:22:33 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:21:38 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA22845 for ; Mon, 24 Mar 2003 14:13:53 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA29797 for ; Mon, 24 Mar 2003 14:05:21 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2OE5LR16865 for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:05:21 GMT Date: Mon, 24 Mar 2003 14:05:21 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: A use for site local addresses? Message-Id: <20030324140521.GD15472@ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I've only just joined the list - I'm mailing about the proposed abandoning of site locals because I'd like to use them! Basically I'm involved in setting up a community wireless network in Southampton, UK. The wireless network itself is a fully routed mesh using private (10.13/16) addresses, the long term goal is to get ISPs to provide internet gateways which you connect to via a VPN, PPPoE or some other method, over which you get a public address. We'd like to start running v6 on the network alongside the 10.13 addresses and site-locals seem like the most sensible choice since it's the only allocation of v6 addresses which is going to be available for us to use and which is large enough to accomodate a /48 per access point (of which there could be hundreds). Obviously the same internet access model could be used so you would get a public prefix over the PPPoE connection. The site-local addresses would only be used for traffic contained within the the wireless mesh, if some areas offered open internet access then they could advertise an additional prefix routed from their own internet connection, thus avoiding any NAT. Well, that's my use and case for Site-Locals in a nut-shell! I realise that this type of deployment is quite a rare case, but I think it represents a legitimate use of private addresses. By the way, another option which would work very well in this type of scenario is the geographical based addressing - http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt Thanks, Mike Saywell Southampton Open Wireless Network http://www.sown.org.uk PhD Student, Dept ECS, Southampton UK. -------------------------------------------------------------------- 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 Mar 24 07:11:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OFBq7f021837; Mon, 24 Mar 2003 07:11:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OFBpDh021836; Mon, 24 Mar 2003 07:11:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OFBm7f021826 for ; Mon, 24 Mar 2003 07:11:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OFBtHP024856 for ; Mon, 24 Mar 2003 07:11:55 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27772 for ; Mon, 24 Mar 2003 08:11:43 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:50:43 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:50:42 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:50:42 Z Received: from c001.snv.cp.net ([209.228.32.119] [209.228.32.119]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 14:50:40 Z Received: (cpmta 5381 invoked from network); 24 Mar 2003 06:49:34 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.119) with SMTP; 24 Mar 2003 06:49:34 -0800 X-Sent: 24 Mar 2003 14:49:34 GMT Message-Id: <00c601c2f214$ca601f40$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: "Mike Saywell" , References: <20030324140521.GD15472@ecs.soton.ac.uk> Subject: Re: A use for site local addresses? Date: Mon, 24 Mar 2003 16:50:57 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01C2F225.8ABA6BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01C2F225.8ABA6BA0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable This could be covered under the prefix FEC0. This is the prefix of a site local address. Site local addresses are = the equivalent of a private IPv4 address. ----- Original Message -----=20 From: "Mike Saywell" To: Sent: Monday, March 24, 2003 4:05 PM Subject: A use for site local addresses? > Hi all, >=20 > I've only just joined the list - I'm mailing about the proposed = abandoning > of site locals because I'd like to use them! >=20 > Basically I'm involved in setting up a community wireless network in > Southampton, UK. The wireless network itself is a fully routed mesh > using private (10.13/16) addresses, the long term goal is to get ISPs > to provide internet gateways which you connect to via a VPN, PPPoE or > some other method, over which you get a public address. >=20 > We'd like to start running v6 on the network alongside the 10.13 = addresses > and site-locals seem like the most sensible choice since it's the only > allocation of v6 addresses which is going to be available for us to = use > and which is large enough to accomodate a /48 per access point (of = which > there could be hundreds). Obviously the same internet access model = could > be used so you would get a public prefix over the PPPoE connection. >=20 > The site-local addresses would only be used for traffic contained = within > the the wireless mesh, if some areas offered open internet access then > they could advertise an additional prefix routed from their own = internet > connection, thus avoiding any NAT. >=20 > Well, that's my use and case for Site-Locals in a nut-shell! I = realise > that this type of deployment is quite a rare case, but I think it > represents a legitimate use of private addresses. >=20 > By the way, another option which would work very well in this type > of scenario is the geographical based addressing - > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt >=20 > Thanks, >=20 > Mike Saywell >=20 > Southampton Open Wireless Network > http://www.sown.org.uk >=20 > PhD Student, Dept ECS, Southampton UK. > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- ------=_NextPart_000_00C1_01C2F225.8ABA6BA0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
This could be covered under = the prefix=20 FEC0.
 
This=20  is=20 the prefix of a site local address. Site local addresses are the = equivalent of a=20 private IPv4 address.
 
----- Original Message -----
From: "Mike Saywell" <ms@ecs.soton.ac.uk>
To: <ipng@sunroof.eng.sun.com>
Sent: Monday, March 24, 2003 4:05 = PM
Subject: A use for site local=20 addresses?

> Hi all,
>
> I've only just joined the list - = I'm=20 mailing about the proposed abandoning
> of site locals because I'd = like to=20 use them!
>
> Basically I'm involved in setting up a = community=20 wireless network in
> Southampton, UK.  The wireless network = itself=20 is a fully routed mesh
> using private (10.13/16) addresses, the = long term=20 goal is to get ISPs
> to provide internet gateways which you = connect to=20 via a VPN, PPPoE or
> some other method, over which you get a = public=20 address.
>
> We'd like to start running v6 on the network = alongside=20 the 10.13 addresses
> and site-locals seem like the most sensible = choice=20 since it's the only
> allocation of v6 addresses which is going to = be=20 available for us to use
> and which is large enough to accomodate = a /48=20 per access point (of which
> there could be hundreds).  = Obviously the=20 same internet access model could
> be used so you would get a = public=20 prefix over the PPPoE connection.
>
> The site-local = addresses=20 would only be used for traffic contained within
> the the wireless = mesh,=20 if some areas offered open internet access then
> they could = advertise an=20 additional prefix routed from their own internet
> connection, = thus=20 avoiding any NAT.
>
> Well, that's my use and case for = Site-Locals=20 in a nut-shell!  I realise
> that this type of deployment is = quite a=20 rare case, but I think it
> represents a legitimate use of private = addresses.
>
> By the way, another option which would work = very=20 well in this type
> of scenario is the geographical based = addressing=20 -
> http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-= 03.txt
>
> Thanks,
>
> Mike = Saywell
>=20
> Southampton Open Wireless Network
> http://www.sown.org.uk
>=20
> PhD Student, Dept ECS, Southampton UK.
>=20 --------------------------------------------------------------------
&= gt;=20 IETF IPng Working Group Mailing List
> IPng Home=20 Page:           &n= bsp;         =20 http://playground.sun.com/ipng
>=20 FTP=20 archive:           = ;          =20 ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo@sunroof.eng.sun.com
>=20 -------------------------------------------------------------------- ------=_NextPart_000_00C1_01C2F225.8ABA6BA0-- -------------------------------------------------------------------- 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 Mar 24 08:59:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OGxY7f022570; Mon, 24 Mar 2003 08:59:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OGxYwg022569; Mon, 24 Mar 2003 08:59:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OGxU7f022562 for ; Mon, 24 Mar 2003 08:59:30 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OGxccU028334 for ; Mon, 24 Mar 2003 08:59:38 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24200 for ; Mon, 24 Mar 2003 08:59:31 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:04:20 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:04:19 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:04:19 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:04:19 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 2003 08:04:17 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D13@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLyEw6uLQtGQrA6QXm8LHS/O+ylpgAC2uzA From: "Michel Py" To: "Mike Saywell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2OGxV7f022563 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, At this point in time I would advise to consider site-local addresses dead. Although I was among those who voted not to deprecate them, the problem needed to be solved and we need to move on. You could use a 6to4 address with an RFC1918 address as the v4 address. For 10.0.0.0/8 this translates into 2002:0A00::/24. Why don't you request a /32 from RIPE anyway? Michel. -----Original Message----- From: Mike Saywell [mailto:ms@ecs.soton.ac.uk] Sent: Monday, March 24, 2003 6:05 AM To: ipng@sunroof.eng.sun.com Subject: A use for site local addresses? Hi all, I've only just joined the list - I'm mailing about the proposed abandoning of site locals because I'd like to use them! Basically I'm involved in setting up a community wireless network in Southampton, UK. The wireless network itself is a fully routed mesh using private (10.13/16) addresses, the long term goal is to get ISPs to provide internet gateways which you connect to via a VPN, PPPoE or some other method, over which you get a public address. We'd like to start running v6 on the network alongside the 10.13 addresses and site-locals seem like the most sensible choice since it's the only allocation of v6 addresses which is going to be available for us to use and which is large enough to accomodate a /48 per access point (of which there could be hundreds). Obviously the same internet access model could be used so you would get a public prefix over the PPPoE connection. The site-local addresses would only be used for traffic contained within the the wireless mesh, if some areas offered open internet access then they could advertise an additional prefix routed from their own internet connection, thus avoiding any NAT. Well, that's my use and case for Site-Locals in a nut-shell! I realise that this type of deployment is quite a rare case, but I think it represents a legitimate use of private addresses. By the way, another option which would work very well in this type of scenario is the geographical based addressing - http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt Thanks, Mike Saywell Southampton Open Wireless Network http://www.sown.org.uk PhD Student, Dept ECS, Southampton UK. -------------------------------------------------------------------- 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 Mar 24 09:15:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OHFU7f022755; Mon, 24 Mar 2003 09:15:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OHFUuu022754; Mon, 24 Mar 2003 09:15:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OHFQ7f022747 for ; Mon, 24 Mar 2003 09:15:27 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OHFYHP002345 for ; Mon, 24 Mar 2003 09:15:34 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22993 for ; Mon, 24 Mar 2003 09:15:28 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:34:19 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:34:19 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:34:19 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:34:18 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA25475 for ; Mon, 24 Mar 2003 16:30:28 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA16452 for ; Mon, 24 Mar 2003 16:30:28 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2OGUSt29113 for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:30:28 GMT Date: Mon, 24 Mar 2003 16:30:27 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030324163027.GA18295@ecs.soton.ac.uk> References: <963621801C6D3E4A9CF454A1972AE8F54D13@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D13@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 24, 2003 at 08:04:17AM -0800, Michel Py wrote: > Mike, > > At this point in time I would advise to consider site-local addresses > dead. Although I was among those who voted not to deprecate them, the > problem needed to be solved and we need to move on. You could use a 6to4 > address with an RFC1918 address as the v4 address. For 10.0.0.0/8 this > translates into 2002:0A00::/24. I could do, but (in my mind) that's worse than using a site-local address! However if the final decision has been made I guess something like this may be the best option, unless... > Why don't you request a /32 from RIPE anyway? I think I may try, I expect cost will be an issue though (i.e. it would have to be free of charge). Thanks for the advice, Mike -------------------------------------------------------------------- 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 Mar 24 09:45:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OHjv7f023399; Mon, 24 Mar 2003 09:45:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OHjvwL023398; Mon, 24 Mar 2003 09:45:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OHjs7f023391 for ; Mon, 24 Mar 2003 09:45:54 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OHk1cU018019 for ; Mon, 24 Mar 2003 09:46:01 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11655 for ; Mon, 24 Mar 2003 09:45:55 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:46:54 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:46:51 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:46:51 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 16:46:25 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2OGiXOI026558; Mon, 24 Mar 2003 17:44:34 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2OGiXxR161446; Mon, 24 Mar 2003 17:44:34 +0100 Received: from gsine08.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35538 from ; Mon, 24 Mar 2003 17:44:30 +0100 Message-Id: <3E7F35AC.C772CB28@hursley.ibm.com> Date: Mon, 24 Mar 2003 17:43:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Mike Saywell Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <20030324140521.GD15472@ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But would there be a problem in using any legitimate /48 prefix instead? Brian Mike Saywell wrote: > > Hi all, > > I've only just joined the list - I'm mailing about the proposed abandoning > of site locals because I'd like to use them! > > Basically I'm involved in setting up a community wireless network in > Southampton, UK. The wireless network itself is a fully routed mesh > using private (10.13/16) addresses, the long term goal is to get ISPs > to provide internet gateways which you connect to via a VPN, PPPoE or > some other method, over which you get a public address. > > We'd like to start running v6 on the network alongside the 10.13 addresses > and site-locals seem like the most sensible choice since it's the only > allocation of v6 addresses which is going to be available for us to use > and which is large enough to accomodate a /48 per access point (of which > there could be hundreds). Obviously the same internet access model could > be used so you would get a public prefix over the PPPoE connection. > > The site-local addresses would only be used for traffic contained within > the the wireless mesh, if some areas offered open internet access then > they could advertise an additional prefix routed from their own internet > connection, thus avoiding any NAT. > > Well, that's my use and case for Site-Locals in a nut-shell! I realise > that this type of deployment is quite a rare case, but I think it > represents a legitimate use of private addresses. > > By the way, another option which would work very well in this type > of scenario is the geographical based addressing - > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt > > Thanks, > > Mike Saywell > > Southampton Open Wireless Network > http://www.sown.org.uk > > PhD Student, Dept ECS, Southampton UK. -------------------------------------------------------------------- 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 Mar 24 09:57:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OHvk7f023935; Mon, 24 Mar 2003 09:57:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OHvkSY023934; Mon, 24 Mar 2003 09:57:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OHvh7f023927 for ; Mon, 24 Mar 2003 09:57:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OHvoHP022679 for ; Mon, 24 Mar 2003 09:57:50 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24307 for ; Mon, 24 Mar 2003 09:57:44 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:33:54 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:33:53 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:33:53 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:33:52 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA26392 for ; Mon, 24 Mar 2003 17:33:47 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA19716 for ; Mon, 24 Mar 2003 17:25:53 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2OHPrA30014 for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:25:53 GMT Date: Mon, 24 Mar 2003 17:25:53 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030324172553.GB18295@ecs.soton.ac.uk> References: <20030324140521.GD15472@ecs.soton.ac.uk> <3E7F35AC.C772CB28@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E7F35AC.C772CB28@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 24, 2003 at 05:43:24PM +0100, Brian E Carpenter wrote: > But would there be a problem in using any legitimate /48 prefix instead? > It's not really enough address space... ideally I think we should be offering each site connected to the network a /48 like an ISP would. I suppose in reality less would be sufficient, perhaps a /56... If everybody connected to the network had a /48 from their ISP it would be ok, but that's not going to be possible for a while. Also if you're giving people a global address, then they would probably expect it to be exactly that (i.e. globally routable). Whereas in this case it wouldn't be... Cheers, Mike -------------------------------------------------------------------- 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 Mar 24 10:03:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OI327f024193; Mon, 24 Mar 2003 10:03:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OI32dh024192; Mon, 24 Mar 2003 10:03:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OI2w7f024182 for ; Mon, 24 Mar 2003 10:02:58 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OI35HP025363 for ; Mon, 24 Mar 2003 10:03:05 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14245 for ; Mon, 24 Mar 2003 10:03:00 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:45:14 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:45:14 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:45:14 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:45:13 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2OHiO4c012776; Mon, 24 Mar 2003 09:44:25 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA00504; Mon, 24 Mar 2003 17:44:26 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Mike Saywell Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? From: Ole Troan Date: Mon, 24 Mar 2003 17:44:26 +0000 In-Reply-To: <20030324163027.GA18295@ecs.soton.ac.uk> (Mike Saywell's message of "Mon, 24 Mar 2003 16:30:27 +0000") Message-Id: <7t5u1dspslh.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <963621801C6D3E4A9CF454A1972AE8F54D13@server2000.arneill-py.sacramento.ca.us> <20030324163027.GA18295@ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> At this point in time I would advise to consider site-local addresses >> dead. Although I was among those who voted not to deprecate them, the >> problem needed to be solved and we need to move on. You could use a 6to4 >> address with an RFC1918 address as the v4 address. For 10.0.0.0/8 this >> translates into 2002:0A00::/24. > > I could do, but (in my mind) that's worse than using a site-local address! > However if the final decision has been made I guess something like this > may be the best option, unless... the IPv6 W.G does not do "final decisions", just wait 6 months and site-locals are back on the table. consensus has to be reached on the mailing list in any case. even though site-locals are discouraged, I would be surprised if the fec0::/10 bit-pattern will be re-allocated to something else. i.e you can safely use them for your purpose. >> Why don't you request a /32 from RIPE anyway? > > I think I may try, I expect cost will be an issue though (i.e. it would > have to be free of charge). public addresses is the best choice. /ot -------------------------------------------------------------------- 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 Mar 24 10:22:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OIMO7f025279; Mon, 24 Mar 2003 10:22:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OIMO2v025278; Mon, 24 Mar 2003 10:22:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OIMK7f025268 for ; Mon, 24 Mar 2003 10:22:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OIMScU005692 for ; Mon, 24 Mar 2003 10:22:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25382 for ; Mon, 24 Mar 2003 11:22:22 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 17:58:05 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP; Mon, 24 Mar 2003 17:57:55 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Mon, 24 Mar 2003 17:57:54 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay2.sun.com with ESMTP; Mon, 24 Mar 2003 17:57:54 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2OHvmQ30333; Mon, 24 Mar 2003 18:57:48 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2OHvmof074401; Mon, 24 Mar 2003 18:57:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303241757.h2OHvmof074401@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: Julien.Laganier@Sun.COM, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Sun, 23 Mar 2003 22:57:21 PST. <200303240657.h2O6v0Aq980322@jurassic.eng.sun.com> Date: Mon, 24 Mar 2003 18:57:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > and it can also satisfy per process behavior. > > => this is not true: I don't want to patch and recompile all applications. > My concern is you provide a device then look for its usage, I prefer to > get requirements and only after look for ways to satify them. I assume these socket options would be applicable more for new type of applications. But I don't see a problem in updating existing application with new socket option and recompile them, if the application wants to serve special cases. For example, it's not surprizing that common network application be modified for running on mobile devices. => Oops, I believe the purpose of your draft is to help Mobile IPv6 deployment... (:-) Also, per-socket control is more desirable than just per-process control, as one application may choose to set different source address for different set of sockets. => what I propose is not pure per-process control, it is to put the control in the context of processes. It gives immediatly a per-process control but with a way to manage the context from applications, it gives a per-socket control too. I don't think threading (as you mentioned before) is a good alternative to that. => first I didn't introduce threading in this discussion, second IMHO you haven't understand my answer about how to implement though-the-context control with threads. > => if there are for each prefix a TMP and a PUBLIC addresses AI_PREFER_SRC_TMP > & co are strictly useless so are candidate for a garbage collection when > we'll run out of bits in ai_flag... I am not sure I understand your point here. => easy, if you have in each prefix a public address and some temporary addresses the flags don't affect the source prefix choice. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 24 11:00:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OJ0e7f026310; Mon, 24 Mar 2003 11:00:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OJ0eTT026309; Mon, 24 Mar 2003 11:00:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OJ0Y7f026302 for ; Mon, 24 Mar 2003 11:00:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OJ0fHP021262 for ; Mon, 24 Mar 2003 11:00:42 -0800 (PST) Received: from esunmail ([129.147.58.198]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20821 for ; Mon, 24 Mar 2003 12:00:36 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HC900IFNOSZS6@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 12:00:36 -0700 (MST) Received: from 192.168.1.100 ([194.2.144.31]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HC900EXYOSW2A@mail.sun.net> for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 12:00:35 -0700 (MST) Date: Mon, 24 Mar 2003 20:00:28 +0100 From: Julien Laganier Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: <200303241757.h2OHvmof074401@givry.rennes.enst-bretagne.fr> To: Francis Dupont , Samita Chakrabarti Cc: Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Message-id: <200303242000.28672.julien.laganier@sun.com> Organization: SUN Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.5 References: <200303241757.h2OHvmof074401@givry.rennes.enst-bretagne.fr> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > In your previous mail you wrote: > > and it can also satisfy per process behavior. > > > > => this is not true: I don't want to patch and recompile all > > applications. My concern is you provide a device then look for its > > usage, I prefer to get requirements and only after look for ways to > > satify them. > > I assume these socket options would be applicable more for new type of > applications. But I don't see a problem in updating existing > application with new socket option and recompile them, if the > application wants to serve special cases. For example, it's not > surprizing that common network application be modified for running > on mobile devices. > > => Oops, I believe the purpose of your draft is to help Mobile IPv6 > deployment... (:-) > > Also, per-socket control is more desirable than just per-process > control, as one application may choose to set different source > address for different set of sockets. > > => what I propose is not pure per-process control, it is to put the > control in the context of processes. It gives immediatly a per-process > control but with a way to manage the context from applications, it gives > a per-socket control too. Though it may be with me with to be able to control this stuff through a process structure, I cannot find how your two points above are related to the goal of that draft which is to help IPv6 deployment. It does not necessarily conflict with your proposition, as it may not be the single _one_ means to tweak address selection. Some type applications may require frequent usage of this sort of tweaking, and it may be boring and not portability-proof to ask devellopers to manage themself these things through sysctl or whatever. The goal of that API is to provide a simple way to manage socket level preference. There is already IPV6_PKT_INFO that allows to manipulate address things, and these options just allows a more loose-grained control over that. Your idea may be a good proposal too and I cannot see why they would be exclusive. > > => if there are for each prefix a TMP and a PUBLIC addresses > > AI_PREFER_SRC_TMP & co are strictly useless so are candidate for a > > garbage collection when we'll run out of bits in ai_flag... > > I am not sure I understand your point here. > > => easy, if you have in each prefix a public address and some temporary > addresses the flags don't affect the source prefix choice. Yes, but there are situations when one does not want to have such a configuration. Thanks, --julien -------------------------------------------------------------------- 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 Mar 24 11:04:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OJ4T7f026899; Mon, 24 Mar 2003 11:04:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OJ4SVY026892; Mon, 24 Mar 2003 11:04:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OJ4B7f026765 for ; Mon, 24 Mar 2003 11:04:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OJ4IHP023194 for ; Mon, 24 Mar 2003 11:04:19 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02720 for ; Mon, 24 Mar 2003 12:04:13 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:04:12 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:04:11 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:04:11 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:04:10 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA10823; Mon, 24 Mar 2003 11:03:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2OJ3jA11004; Mon, 24 Mar 2003 11:03:45 -0800 X-mProtect: <200303241903> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyLo8qm; Mon, 24 Mar 2003 11:03:44 PST Message-Id: <3E7F57F5.9050304@iprg.nokia.com> Date: Mon, 24 Mar 2003 11:09:41 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Saywell CC: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <20030324140521.GD15472@ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is very close to the use case I referred to at the microphone during the Thursday session in San Francisco when I spoke of intermittently-connected networks. Take for example an ad-hoc/mesh network that travels together and may from time to time lose connection with the global Internet; perhaps reconnecting at a different point of attachment at some later time. While detached, the nodes in the intermittently-connected network should still be able to communicate with one another. But, when reconnecting to a different point of attachment, ongoing intra-network communications should not be impacted by monolithic renumbering events. Site-locals seem like a natural mechanism for such use cases, but if they are to be deprecated a different scheme is needed. Possibilities include having one or more nodes in the intermittently-connected network "own" a global prefix that gets injected into the global routing tables at the current point of attachment, a geo-addressing scheme such as the one referred to below, or perhaps some new scheme that is yet to be identified. IMO, use cases such as these need to be identified and addressed in whatever mechanisms are chosen as we move forward. New ideas and further discussion along these lines would probably be a good thing. Fred Templin ftemplin@iprg.nokia.com Mike Saywell wrote: > Hi all, > > I've only just joined the list - I'm mailing about the proposed abandoning > of site locals because I'd like to use them! > > Basically I'm involved in setting up a community wireless network in > Southampton, UK. The wireless network itself is a fully routed mesh > using private (10.13/16) addresses, the long term goal is to get ISPs > to provide internet gateways which you connect to via a VPN, PPPoE or > some other method, over which you get a public address. > > We'd like to start running v6 on the network alongside the 10.13 addresses > and site-locals seem like the most sensible choice since it's the only > allocation of v6 addresses which is going to be available for us to use > and which is large enough to accomodate a /48 per access point (of which > there could be hundreds). Obviously the same internet access model could > be used so you would get a public prefix over the PPPoE connection. > > The site-local addresses would only be used for traffic contained within > the the wireless mesh, if some areas offered open internet access then > they could advertise an additional prefix routed from their own internet > connection, thus avoiding any NAT. > > Well, that's my use and case for Site-Locals in a nut-shell! I realise > that this type of deployment is quite a rare case, but I think it > represents a legitimate use of private addresses. > > By the way, another option which would work very well in this type > of scenario is the geographical based addressing - > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt > > Thanks, > > Mike Saywell > > Southampton Open Wireless Network > http://www.sown.org.uk > > PhD Student, Dept ECS, Southampton UK. > -------------------------------------------------------------------- > 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 Mar 24 11:33:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OJXL7f028754; Mon, 24 Mar 2003 11:33:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OJXLIe028753; Mon, 24 Mar 2003 11:33:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OJXI7f028746 for ; Mon, 24 Mar 2003 11:33:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OJXPcU006911 for ; Mon, 24 Mar 2003 11:33:25 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10251 for ; Mon, 24 Mar 2003 11:33:19 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:33:18 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:33:13 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:33:13 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 19:33:12 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2OJXGwY031764; Mon, 24 Mar 2003 21:33:16 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2OJXDrB031763; Mon, 24 Mar 2003 21:33:13 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: comments on the address selection API draft From: Mika Liljeberg To: Erik Nordmark Cc: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= , Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048534392.12764.11.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Mar 2003 21:33:13 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 2003-03-24 at 12:42, Erik Nordmark wrote: > Thus not specifying either of "X" and "not X" leaves the "X" property of > the address selection at the system default. And if the application specifies both "X" and "not X"? In a classic adventure game by Douglas Adams the ability to do this would have constituted proof of superior intelligence, however here it is clearly an illegal combination. Having a lot of illegal parameter combinations in an API is not very desirable, as it requires extra sanity checks in the implementation. > An alternate API would be to have one flag per property and always require a > get before a set. I think I would prefer this approach. This is clean, no special cases, and allows simple checking of system defaults. The application can always store the default bit vector if it creates multiple sockets. MikaL -------------------------------------------------------------------- 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 Mar 24 12:00:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OK0v7f029414; Mon, 24 Mar 2003 12:00:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OK0vXM029413; Mon, 24 Mar 2003 12:00:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OK0o7f029398 for ; Mon, 24 Mar 2003 12:00:51 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OK0wHP015323 for ; Mon, 24 Mar 2003 12:00:58 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14896 for ; Mon, 24 Mar 2003 12:00:52 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:00:52 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:00:52 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:00:52 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:00:51 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2OK0Ab15470; Mon, 24 Mar 2003 22:00:10 +0200 Date: Mon, 24 Mar 2003 22:00:09 +0200 (EET) From: Pekka Savola To: "Fred L. Templin" cc: Mike Saywell , Subject: Re: A use for site local addresses? In-Reply-To: <3E7F57F5.9050304@iprg.nokia.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 24 Mar 2003, Fred L. Templin wrote: > This is very close to the use case I referred to at the microphone > during the Thursday session in San Francisco when I spoke of > intermittently-connected networks. Take for example an ad-hoc/mesh > network that travels together and may from time to time lose connection > with the global Internet; perhaps reconnecting at a different point > of attachment at some later time. While detached, the nodes in the > intermittently-connected network should still be able to communicate > with one another. But, when reconnecting to a different point of > attachment, ongoing intra-network communications should not be > impacted by monolithic renumbering events. [...] This case could work if you just use addresses with a lifetime long enough to survive the disconnection (and deprecate the addresses immediately when you reconnect and start using new ones). It's bit of a hack, and details have to be worked out to see if there are any gaps in this (one is that you can't deprecate an address faster than 2 hours unless IPsec is used). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 24 12:41:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OKfc7f000436; Mon, 24 Mar 2003 12:41:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OKfciK000435; Mon, 24 Mar 2003 12:41:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OKfZ7f000428 for ; Mon, 24 Mar 2003 12:41:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OKfgcU004012 for ; Mon, 24 Mar 2003 12:41:42 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12119 for ; Mon, 24 Mar 2003 13:41:21 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:41:19 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:41:19 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:41:19 Z Received: from laptop2.kurtis.autonomica.se ([195.43.225.70] [195.43.225.70]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 20:41:18 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2OKggKW010892; Mon, 24 Mar 2003 21:42:47 +0100 (CET) Date: Mon, 24 Mar 2003 21:42:42 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Mike Saywell From: Kurt Erik Lindqvist In-Reply-To: <20030324163027.GA18295@ecs.soton.ac.uk> Message-Id: <28C64038-5E39-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Why don't you request a /32 from RIPE anyway? > > I think I may try, I expect cost will be an issue though (i.e. it would > have to be free of charge). Ask a ISP that is registered as LIR at RIPE. - kurtis - -------------------------------------------------------------------- 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 Mar 24 13:46:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OLkc7f001414; Mon, 24 Mar 2003 13:46:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2OLkbvZ001413; Mon, 24 Mar 2003 13:46:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2OLkY7f001406 for ; Mon, 24 Mar 2003 13:46:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2OLkfcU024623 for ; Mon, 24 Mar 2003 13:46:41 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14145 for ; Mon, 24 Mar 2003 14:46:32 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 24 Mar 2003 21:46:20 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP; Mon, 24 Mar 2003 21:46:15 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Mon, 24 Mar 2003 21:46:15 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay1.sun.com with ESMTP; Mon, 24 Mar 2003 21:46:15 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2OLkAQ03502; Mon, 24 Mar 2003 22:46:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2OLkAof075108; Mon, 24 Mar 2003 22:46:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303242146.h2OLkAof075108@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Julien Laganier cc: Samita Chakrabarti , Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Mon, 24 Mar 2003 20:00:28 +0100. <200303242000.28672.julien.laganier@sun.com> Date: Mon, 24 Mar 2003 22:46:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The goal of that API is to provide a simple way to manage socket level preference. => my concern is your goal is to fulfill a requirement from developpers than my goal is to fulfill a similar requirement from users. As there are far more users than developpers and as developpers are users too and as my proposal works for both users and developpers, I consider you are just solving the wrong problem... There is already IPV6_PKT_INFO that allows to manipulate address things, and these options just allows a more loose-grained control over that. => I don't believe that IPV6_PKT_INFO is a good example of a developper friendly device (:-). Your idea may be a good proposal too and I cannot see why they would be exclusive. => they are not exclusive but we should work first on the most flexible/ general one. And before ask users about what they'd like to get. As an user my immediate needs are: - a policy table in the context - a global flag to choose the largest scope - nothing about home/care-of or temporary/public as I don't use these features. Today I have (in recent KAME codes) only a global policy table which is not enough on multi-user boxes. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 24 18:28:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P2St7f003872; Mon, 24 Mar 2003 18:28:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2P2StqV003871; Mon, 24 Mar 2003 18:28:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P2Sp7f003864 for ; Mon, 24 Mar 2003 18:28:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2P2SwHP026693 for ; Mon, 24 Mar 2003 18:28:59 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA19078 for ; Mon, 24 Mar 2003 19:28:53 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 02:28:51 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 02:27:44 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 02:27:44 Z Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 02:27:43 Z Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3560E4B22; Tue, 25 Mar 2003 11:27:39 +0900 (JST) To: "" Cc: ipng@sunroof.eng.sun.com In-reply-to: kuntal's message of Sun, 23 Mar 2003 12:29:39 PST. <428770ac5e7647c5a7d4ab3717bd9900.kuntal@iqmail.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DAD in node requirements draft From: itojun@iijlab.net Date: Tue, 25 Mar 2003 11:27:39 +0900 Message-Id: <20030325022739.3560E4B22@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Please explain why running DAD for an autoconfigured non-link >local address based on IID received from IPv6CP and prefix received >from RA makes sense to you. it makes more sense when rules are simpler. if you always perform DAD you can always ensure there's no duplicate. even if machine A is autoconfigured with prefix P::/64 and DAD-safe link-local address fe80::ID, the other end could configure P:ID intentionally. itojun -------------------------------------------------------------------- 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 Mar 24 19:43:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P3ha7f004230; Mon, 24 Mar 2003 19:43:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2P3hZLa004229; Mon, 24 Mar 2003 19:43:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P3hW7f004222 for ; Mon, 24 Mar 2003 19:43:32 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2P3heHP013766 for ; Mon, 24 Mar 2003 19:43:40 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16419 for ; Mon, 24 Mar 2003 19:43:34 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 03:43:34 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 03:40:43 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 03:43:33 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 03:43:33 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Mar 2003 19:43:33 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D18@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLyKduXtgE3BIS/RjupDcYmsCmrgQAUoFxw From: "Michel Py" To: "Mike Saywell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2P3hW7f004223 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, >> Michel Py wrote: >> At this point in time I would advise to consider site-local >> addresses dead. Although I was among those who voted not to >> deprecate them, the problem needed to be solved and we need >> to move on. You could use a 6to4 address with an RFC1918 >> address as the v4 address. For 10.0.0.0/8 this translates >> into 2002:0A00::/24. > Mike Saywell wrote: > I could do, but (in my mind) that's worse than using a > site-local address! That's what I also think but you have to do with what you have on the shelf. I actually don't recommend using FECO::/10 anymore although it is more than probable that it will not be reallocated to another use any time soon. In the midterm you might find implementations that hardcode a blackhole. > However if the final decision has been made I guess something > like this may be the best option, unless... The final decision has not been made; what is decided during WG meetings needs to be confirmed on the mailing list. However, given the fact that some pro site-locals such as myself will recommend going with ahead with the deprecation for the sake of not staying stuck on this for years.... Michel. -------------------------------------------------------------------- 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 Mar 25 00:45:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P8jU7f005255; Tue, 25 Mar 2003 00:45:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2P8jU5L005254; Tue, 25 Mar 2003 00:45:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P8jQ7f005247 for ; Tue, 25 Mar 2003 00:45:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2P8jZcU024989 for ; Tue, 25 Mar 2003 00:45:35 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05222 for ; Tue, 25 Mar 2003 01:45:29 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 08:45:29 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 08:42:38 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 08:45:28 Z Received: from c001.snv.cp.net ([209.228.32.122] [209.228.32.122]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 08:45:28 Z Received: (cpmta 4427 invoked from network); 25 Mar 2003 00:45:26 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.122) with SMTP; 25 Mar 2003 00:45:26 -0800 X-Sent: 25 Mar 2003 08:45:26 GMT Message-Id: <00c601c2f2ab$16a92b30$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <20030324140521.GD15472@ecs.soton.ac.uk> <00c601c2f214$ca601f40$67061eac@ttitelecom.com> <20030324165446.GA14193@login.ecs.soton.ac.uk> Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 10:46:50 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When did site local addresses die and why? I changed companies and missed several months of discussion. Currently I am working on NMS related changes based on: * FE8, FE9, FEA, and FEB are Link local addresses * FEC0 is the prefix of a site local address. Site local addresses are the equivalent of a private IPv4 address As stated by several other comments recently, I see taht there is not a consensus about the fate of Link local addresses. To many people are used to thinking of using the 10 net as their local (corporate or internal) address space. If we do not take this into account then these people will adopt ::10:X:X:X:X as the local addresses just as before. When this is related to large companies and their internal (not addressable fro the public Internet) hardware they still need some sort of site or organization local addresses. We can not pass this by just to prevet slowing otherthings down. There are too many documents out there that refer to FEC0 as the site local, so you will not be able to use it for other applications, thus we will have a de facto standard based on old information while the offical standard will have no alternate. We must take the lead on this issue. Eric Klein NGN Solutions Manager TTI Team Telecom International ----- Original Message ----- From: "Tim Chown" To: "EricLKlein" Sent: Monday, March 24, 2003 6:54 PM Subject: Re: A use for site local addresses? > Read the email. Site locals are dead, hence the question :) > > On Mon, Mar 24, 2003 at 04:50:57PM +0200, EricLKlein wrote: > > This could be covered under the prefix FEC0. > > > > This is the prefix of a site local address. Site local addresses are the equivalent of a private IPv4 address. > > > > ----- Original Message ----- > > From: "Mike Saywell" > > To: > > Sent: Monday, March 24, 2003 4:05 PM > > Subject: A use for site local addresses? > > > > > > > Hi all, > > > > > > I've only just joined the list - I'm mailing about the proposed abandoning > > > of site locals because I'd like to use them! > > > > > > Basically I'm involved in setting up a community wireless network in > > > Southampton, UK. The wireless network itself is a fully routed mesh > > > using private (10.13/16) addresses, the long term goal is to get ISPs > > > to provide internet gateways which you connect to via a VPN, PPPoE or > > > some other method, over which you get a public address. > > > > > > We'd like to start running v6 on the network alongside the 10.13 addresses > > > and site-locals seem like the most sensible choice since it's the only > > > allocation of v6 addresses which is going to be available for us to use > > > and which is large enough to accomodate a /48 per access point (of which > > > there could be hundreds). Obviously the same internet access model could > > > be used so you would get a public prefix over the PPPoE connection. > > > > > > The site-local addresses would only be used for traffic contained within > > > the the wireless mesh, if some areas offered open internet access then > > > they could advertise an additional prefix routed from their own internet > > > connection, thus avoiding any NAT. > > > > > > Well, that's my use and case for Site-Locals in a nut-shell! I realise > > > that this type of deployment is quite a rare case, but I think it > > > represents a legitimate use of private addresses. > > > > > > By the way, another option which would work very well in this type > > > of scenario is the geographical based addressing - > > > http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt > > > > > > Thanks, > > > > > > Mike Saywell > > > > > > Southampton Open Wireless Network > > > http://www.sown.org.uk > > > > > > PhD Student, Dept ECS, Southampton UK. > > > -------------------------------------------------------------------- > > > 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 Tue Mar 25 01:05:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P95Z7f005559; Tue, 25 Mar 2003 01:05:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2P95Ze1005558; Tue, 25 Mar 2003 01:05:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P95T7f005551 for ; Tue, 25 Mar 2003 01:05:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2P95ccU029389 for ; Tue, 25 Mar 2003 01:05:38 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27366 for ; Tue, 25 Mar 2003 02:05:32 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:05:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:05:30 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:05:29 Z Received: from c001.snv.cp.net ([209.228.32.119] [209.228.32.119]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:05:29 Z Received: (cpmta 25088 invoked from network); 25 Mar 2003 01:05:27 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.119) with SMTP; 25 Mar 2003 01:05:27 -0800 X-Sent: 25 Mar 2003 09:05:27 GMT Message-Id: <00d201c2f2ad$e24ee340$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <751C3918-5EA0-11D7-B5E2-000393AB1404@kurtis.pp.se> Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 11:06:53 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The same people are also trying to understand why a number of > applications doesn't work in their network and how come that trojan > send their password file to a unknown destination. Private addresses > comes at a cost that is becoming more and more apparent. No need to pay > that price in IPv6 as well as in IPv4. > > If you absolutely want NAT take a random address block and NAT it for > you. You will get the same problems / benefits. Who is going to priovide the registered addresses that will be used for all corporations and at what price? Most companies will not want to have to pay for a public address for all their printers and copiers (and microwaves as those are added by Microsoft). > Site-locals was voted down in the WG meeting in SF. How do those of us who can not attend these conferences get into these limited participation votes? I for one can not make frequent international trips for a non-customer related meeting. -------------------------------------------------------------------- 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 Mar 25 01:06:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P96I7f005597; Tue, 25 Mar 2003 01:06:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2P96I9R005596; Tue, 25 Mar 2003 01:06:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P96C7f005582 for ; Tue, 25 Mar 2003 01:06:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2P96KcU029503 for ; Tue, 25 Mar 2003 01:06:20 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19393 for ; Tue, 25 Mar 2003 02:06:14 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:01:04 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:00:45 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:00:45 Z Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:00:45 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2P929KW011145; Tue, 25 Mar 2003 10:02:10 +0100 (CET) Date: Tue, 25 Mar 2003 10:02:08 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "EricLKlein" From: Kurt Erik Lindqvist In-Reply-To: <00c601c2f2ab$16a92b30$67061eac@ttitelecom.com> Message-Id: <751C3918-5EA0-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > To many people are used to thinking of using the 10 net as their local > (corporate or internal) address space. If we do not take this into > account The same people are also trying to understand why a number of applications doesn't work in their network and how come that trojan send their password file to a unknown destination. Private addresses comes at a cost that is becoming more and more apparent. No need to pay that price in IPv6 as well as in IPv4. If you absolutely want NAT take a random address block and NAT it for you. You will get the same problems / benefits. Site-locals was voted down in the WG meeting in SF. - kurtis - -------------------------------------------------------------------- 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 Mar 25 01:17:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P9H87f006054; Tue, 25 Mar 2003 01:17:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2P9H8q2006053; Tue, 25 Mar 2003 01:17:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P9H47f006046 for ; Tue, 25 Mar 2003 01:17:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2P9HDcU002468 for ; Tue, 25 Mar 2003 01:17:13 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27332 for ; Tue, 25 Mar 2003 02:17:07 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:17:05 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:17:05 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:17:04 Z Received: from klapautius.it.su.se ([130.237.152.81] [130.237.152.81]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:17:03 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2P9DxC01851; Tue, 25 Mar 2003 10:14:11 +0100 Message-Id: <3E801DD7.8010803@it.su.se> Date: Tue, 25 Mar 2003 10:13:59 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: EricLKlein CC: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <20030324140521.GD15472@ecs.soton.ac.uk> <00c601c2f214$ca601f40$67061eac@ttitelecom.com> <20030324165446.GA14193@login.ecs.soton.ac.uk> <00c601c2f2ab$16a92b30$67061eac@ttitelecom.com> In-Reply-To: <00c601c2f2ab$16a92b30$67061eac@ttitelecom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: >When did site local addresses die and why? I changed companies and missed >several months of discussion. > >Currently I am working on NMS related changes based on: >* FE8, FE9, FEA, and FEB are Link local addresses >* FEC0 is the prefix of a site local address. Site local addresses are the >equivalent of a private IPv4 address > >As stated by several other comments recently, I see taht there is not a >consensus about the fate of Link local addresses. > >To many people are used to thinking of using the 10 net as their local >(corporate or internal) address space. If we do not take this into account >then these people will adopt ::10:X:X:X:X as the local addresses just as >before. When this is related to large companies and their internal (not >addressable fro the public Internet) hardware they still need some sort of >site or organization local addresses. > >We can not pass this by just to prevet slowing otherthings down. There are >too many documents out there that refer to FEC0 as the site local, so you >will not be able to use it for other applications, thus we will have a de >facto standard based on old information while the offical standard will have >no alternate. > > > Let's please remember that the architechture devised here will primarily be used to run _applications_. Long experience shows that private addresses in any form are a bad idea on the Internet. This was discussed at length on the v6 wg meeting last week and I believe that deprecating sl is the best we can do. leifj -------------------------------------------------------------------- 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 Mar 25 01:35:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P9Z67f006145; Tue, 25 Mar 2003 01:35:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2P9Z6bF006144; Tue, 25 Mar 2003 01:35:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2P9Z37f006137 for ; Tue, 25 Mar 2003 01:35:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2P9ZBHP024424 for ; Tue, 25 Mar 2003 01:35:11 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03549 for ; Tue, 25 Mar 2003 02:35:06 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:35:05 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:35:05 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:35:05 Z Received: from c001.snv.cp.net ([209.228.32.122] [209.228.32.122]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 09:35:05 Z Received: (cpmta 7308 invoked from network); 25 Mar 2003 01:35:03 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.122) with SMTP; 25 Mar 2003 01:35:03 -0800 X-Sent: 25 Mar 2003 09:35:03 GMT Message-Id: <00f101c2f2b2$04e719f0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <20030324140521.GD15472@ecs.soton.ac.uk> <00c601c2f214$ca601f40$67061eac@ttitelecom.com> <20030324165446.GA14193@login.ecs.soton.ac.uk> <00c601c2f2ab$16a92b30$67061eac@ttitelecom.com> <3E801DD7.8010803@it.su.se> Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 11:36:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01C2F2C2.C6C40EB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C2F2C2.C6C40EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 Leif Johansson wrote: > Let's please remember that the architechture devised here will = primarily=20 > be used to > run _applications_. Long experience shows that private addresses in = any=20 > form are a > bad idea on the Internet. This was discussed at length on the v6 wg=20 > meeting last week > and I believe that deprecating sl is the best we can do. >=20 I am willing to admit that there are big problems with private = addresses, but a simple search on www.yahoo.com for=20 +ipv6 +"local address"=20 The results are 13,400 pages. We need to define this very clearly and get it out there as the already = too much confusion as to how it is recommended to implement this. At = least two people have posted that they don't think that the fe80:: range = will be able to be used due to this prepublication of the concept (see = draft-itojun-ipv6-local-experiment-00.txt for example). As a recommendation team we need to offer an alternative not just a "the = old way was bad so don't used it anymore" kind of answer.=20 I understand that there was a discussion and vote in SF, great. Who is = going to put out a new draft-RFC that will explain this clearly enough = that end-user implementation people (think LAN installation) will = understand it and will be willing to work with it. They have a history = of doing the old way why should they change now?=20 ------=_NextPart_000_00EE_01C2F2C2.C6C40EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
Leif Johansson wrote:

> Let's = please=20 remember that the architechture devised here will primarily
> be = used=20 to
> run _applications_. Long experience shows that private = addresses in=20 any
> form are a
> bad idea on the Internet. This was = discussed at=20 length on the v6 wg
> meeting last week
> and I believe = that=20 deprecating sl is the best we can do.
>
I am willing to admit that there are = big problems=20 with private addresses, but a simple search on www.yahoo.com for
 
+ipv6 +"local = address" 
 
The results are 13,400 = pages.
 
We need to define this very clearly and = get it out=20 there as the already too much confusion as to how it is recommended to = implement=20 this. At least two people have posted that they don't think that the = fe80::=20 range will be able to be used due to this prepublication of the concept = (see=20 draft-itojun-ipv6-local-experiment-00.txt for example).
 
As a recommendation team we need to = offer an=20 alternative not just a "the old way was bad so don't used it anymore" = kind of=20 answer.
 
I understand that there was a = discussion and vote=20 in SF, great. Who is going to put out a new draft-RFC that will explain = this=20 clearly enough that end-user implementation people (think LAN = installation) will=20 understand it and will be willing to work with it. They have a history = of doing=20 the old way why should they change now?
 
 
------=_NextPart_000_00EE_01C2F2C2.C6C40EB0-- -------------------------------------------------------------------- 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 Mar 25 02:03:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PA3k7f006629; Tue, 25 Mar 2003 02:03:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PA3kFl006628; Tue, 25 Mar 2003 02:03:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PA3g7f006621 for ; Tue, 25 Mar 2003 02:03:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PA3pcU012726 for ; Tue, 25 Mar 2003 02:03:51 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19713 for ; Tue, 25 Mar 2003 03:03:45 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:03:34 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:03:34 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:03:33 Z Received: from paddock.ermy.net (paddock.ermy.net [62.189.30.132]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:03:33 Z Received: (qmail 5893 invoked by uid 500); 25 Mar 2003 10:03:31 -0000 Date: Tue, 25 Mar 2003 10:03:31 +0000 From: Mark Thompson To: Leif Johansson Cc: EricLKlein , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030325100331.GK25851@paddock.ermy.net> References: <20030324140521.GD15472@ecs.soton.ac.uk> <00c601c2f214$ca601f40$67061eac@ttitelecom.com> <20030324165446.GA14193@login.ecs.soton.ac.uk> <00c601c2f2ab$16a92b30$67061eac@ttitelecom.com> <3E801DD7.8010803@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E801DD7.8010803@it.su.se> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk * Leif Johansson 20030325.0913: > > Long experience shows that private addresses in any > form are a > bad idea on the Internet. But what I understand of Saywell's requirement is that this isn't the Internet (big 'I'). It is _an_ internet, whose topology changes shape, albeit not too frequently. Sometimes, some parts of this internet have links to the Internet, and so will see globally routable address prefixes that may be propagated to all the nodes in the 'site', meaning that every participant node in Saywell's network will (for that time at least) have 'n' globally routable addresses from the 'n' nodes that have links up to the Big-I. However, that level of connectivity is ephemeral at best, for the target audience, as I perceive it, includes people having nodes on dial-up lines (therefore potentially getting a different global prefix on each connection), DSL lines, and vary rarely any form of fixed provider (its a community networking activity, right?). Therefore, it is *not* clear that the nodes will have any form of known/fixed/reliable address that they can communicate with each other internally and, given that this is a multi-link network, there is a desire for something that looks a lot like site local addressing. (Or have I misinterpreted the application?) Mark/ -- "There are no stupid questions, just stupid people" - Mr. Garrison, South Park, CO -------------------------------------------------------------------- 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 Mar 25 02:06:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PA627f006676; Tue, 25 Mar 2003 02:06:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PA62KD006675; Tue, 25 Mar 2003 02:06:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PA5x7f006665 for ; Tue, 25 Mar 2003 02:05:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PA67HP000937 for ; Tue, 25 Mar 2003 02:06:07 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21102 for ; Tue, 25 Mar 2003 03:06:02 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:06:01 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:06:00 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:06:00 Z Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:06:00 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2PA7NKW011154; Tue, 25 Mar 2003 11:07:23 +0100 (CET) Date: Tue, 25 Mar 2003 11:07:21 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "EricLKlein" From: Kurt Erik Lindqvist In-Reply-To: <00d201c2f2ad$e24ee340$67061eac@ttitelecom.com> Message-Id: <91CA1DD0-5EA9-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> If you absolutely want NAT take a random address block and NAT it for >> you. You will get the same problems / benefits. > > Who is going to priovide the registered addresses that will be used > for all > corporations and at what price? Most companies will not want to have > to pay > for a public address for all their printers and copiers (and > microwaves as > those are added by Microsoft). You can get addresses from your upstream provider. > >> Site-locals was voted down in the WG meeting in SF. > How do those of us who can not attend these conferences get into these > limited participation votes? I for one can not make frequent > international > trips for a non-customer related meeting. > The vote needs to be confirmed on the mailinglist so you will have an opportunity to vote. However, the vote in SF was pretty clear. - kurtis - -------------------------------------------------------------------- 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 Mar 25 02:16:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PAGp7f007016; Tue, 25 Mar 2003 02:16:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PAGpNt007015; Tue, 25 Mar 2003 02:16:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PAGm7f007008 for ; Tue, 25 Mar 2003 02:16:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PAGuHP003512 for ; Tue, 25 Mar 2003 02:16:56 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27718 for ; Tue, 25 Mar 2003 03:16:51 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:16:50 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:16:50 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:16:50 Z Received: from klapautius.it.su.se ([130.237.152.81] [130.237.152.81]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:16:49 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2PADlC01867; Tue, 25 Mar 2003 11:13:53 +0100 Message-Id: <3E802BDB.1010504@it.su.se> Date: Tue, 25 Mar 2003 11:13:47 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Thompson CC: EricLKlein , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <20030324140521.GD15472@ecs.soton.ac.uk> <00c601c2f214$ca601f40$67061eac@ttitelecom.com> <20030324165446.GA14193@login.ecs.soton.ac.uk> <00c601c2f2ab$16a92b30$67061eac@ttitelecom.com> <3E801DD7.8010803@it.su.se> <20030325100331.GK25851@paddock.ermy.net> In-Reply-To: <20030325100331.GK25851@paddock.ermy.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark Thompson wrote: > > No matter how you capitalize the word, it still needs to run the same applications! Applications must not know about topology. Period. -------------------------------------------------------------------- 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 Mar 25 03:21:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBLf7f007490; Tue, 25 Mar 2003 03:21:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PBLfij007489; Tue, 25 Mar 2003 03:21:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBLc7f007482 for ; Tue, 25 Mar 2003 03:21:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PBLjHP015569 for ; Tue, 25 Mar 2003 03:21:45 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22653 for ; Tue, 25 Mar 2003 03:59:58 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:59:57 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:59:57 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:59:57 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 10:59:56 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id E2A258F55; Tue, 25 Mar 2003 11:59:51 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id EA3EC8AFF; Tue, 25 Mar 2003 11:59:43 +0100 (CET) From: "Jeroen Massar" To: "'Leif Johansson'" , "'Mark Thompson'" Cc: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 12:00:45 +0100 Organization: Unfix Message-Id: <003401c2f2bd$c9d18f10$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3E802BDB.1010504@it.su.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PBLc7f007483 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Leif Johansson wrote: > Mark Thompson wrote: > > > > > > No matter how you capitalize the word, it still needs to run the same > applications! Applications must not know about topology. Period. I am also *against* Link local. IP's should be globably unique. Which will overcome many problems like network mergers ('oh we need to NAT now'), e2e problems etc. They can be handy for some situations, but those situations will impose bigger problems later on requiring strange solutions for something which could be so simple without all of this. If you want security -> firewall or simply don't route the block ;) And it should be quite possible for anybody to use one /64 out of their /48 for 'printers' and 'microwaves'. Not even talking about refridgerators full with IPv6 beer (seen that one already :) I would like to give those appliances globally routable IP space simply because it would allow my printer to order new paper from the store when it's almost out. Or better... new beer in my fridge! Greets, Jeroen -------------------------------------------------------------------- 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 Mar 25 03:45:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBj97f008472; Tue, 25 Mar 2003 03:45:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PBj8n9008471; Tue, 25 Mar 2003 03:45:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBj57f008464 for ; Tue, 25 Mar 2003 03:45:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PBjCHP020201 for ; Tue, 25 Mar 2003 03:45:13 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26652 for ; Tue, 25 Mar 2003 04:45:06 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:45:06 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:45:06 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:45:06 Z Received: from c001.snv.cp.net ([209.228.32.114] [209.228.32.114]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:45:06 Z Received: (cpmta 4304 invoked from network); 25 Mar 2003 03:45:04 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.114) with SMTP; 25 Mar 2003 03:45:04 -0800 X-Sent: 25 Mar 2003 11:45:04 GMT Message-Id: <010601c2f2c4$2ebdd5e0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <91CA1DD0-5EA9-11D7-B5E2-000393AB1404@kurtis.pp.se> Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 13:46:30 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Kurt Erik Lindqvist" To: "EricLKlein" Cc: Sent: Tuesday, March 25, 2003 12:07 PM Subject: Re: A use for site local addresses? > >> If you absolutely want NAT take a random address block and NAT it for > >> you. You will get the same problems / benefits. > > > > Who is going to priovide the registered addresses that will be used > > for all > > corporations and at what price? Most companies will not want to have > > to pay > > for a public address for all their printers and copiers (and > > microwaves as > > those are added by Microsoft). > > You can get addresses from your upstream provider. Ok, if I understand this from a hardware (not application) point of view a company like IBM (or any other large company with multiple sites) will be required to pay an upstream provider for (private) local IP addresses for their printers. Think about it, at the hardware side of this we are encouraging them to keep using IPv4 for those items that will not be connected to the public internet. Or to look at it another way, the Macintosh computers on a LAN that used to broadcast a request for every printer on a network whenever the printer dialogue box was opened. With no local distinctions then entire WAN will be polled for printers, if not the entire Internet. We need to find some way to filter or block this kind of activity. -------------------------------------------------------------------- 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 Mar 25 03:53:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBrJ7f008724; Tue, 25 Mar 2003 03:53:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PBrJ30008723; Tue, 25 Mar 2003 03:53:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBrF7f008716 for ; Tue, 25 Mar 2003 03:53:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PBrNcU004848 for ; Tue, 25 Mar 2003 03:53:23 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05162 for ; Tue, 25 Mar 2003 04:53:18 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:17 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:17 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:16 Z Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:16 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2PBscKW011202; Tue, 25 Mar 2003 12:54:38 +0100 (CET) Date: Tue, 25 Mar 2003 12:54:37 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Leif Johansson'" , "'Mark Thompson'" , "'EricLKlein'" , To: "Jeroen Massar" From: Kurt Erik Lindqvist In-Reply-To: <003401c2f2bd$c9d18f10$210d640a@unfix.org> Message-Id: <8DCA4CE5-5EB8-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On tisdag, mar 25, 2003, at 12:00 Europe/Stockholm, Jeroen Massar wrote: > > I am also *against* Link local. Sure you did not mean site-local? - kurtis - -------------------------------------------------------------------- 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 Mar 25 03:53:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBrR7f008737; Tue, 25 Mar 2003 03:53:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PBrQRb008736; Tue, 25 Mar 2003 03:53:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBrK7f008729 for ; Tue, 25 Mar 2003 03:53:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PBrSHP021814 for ; Tue, 25 Mar 2003 03:53:28 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15172 for ; Tue, 25 Mar 2003 04:53:23 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:22 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:50:30 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:20 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:20 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA06642 for ; Tue, 25 Mar 2003 11:53:19 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA21051 for ; Tue, 25 Mar 2003 11:53:19 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2PBrJV17444 for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:53:19 GMT Date: Tue, 25 Mar 2003 11:53:19 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030325115319.GI18295@ecs.soton.ac.uk> References: <3E802BDB.1010504@it.su.se> <003401c2f2bd$c9d18f10$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c2f2bd$c9d18f10$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 25, 2003 at 12:00:45PM +0100, Jeroen Massar wrote: > Leif Johansson wrote: > > > Mark Thompson wrote: > > > > > > > > > > No matter how you capitalize the word, it still needs to run the same > > applications! Applications must not know about topology. Period. > > I am also *against* Link local. > > IP's should be globably unique. Which will overcome many problems > like network mergers ('oh we need to NAT now'), e2e problems etc. This is very true, but there are certain scenarios (like the network I've described) where we have a need for a large number of addresses, which dont require to be globally routable (since network is self-contained). If it was possible to use global addresses then I would, however rules regarding the IPv6 address space allocation make this a near impossibility for us. :( I can't really see the motivations to do NAT under v6 when it's so easy to have multiple addresses on an interface anyway. Joining 2 networks which use the same address site-local addresses would be nowhere near as painfull as before since it's that much easier to re-number one of them under v6. Cheers, Mike -------------------------------------------------------------------- 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 Mar 25 03:55:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBtk7f008841; Tue, 25 Mar 2003 03:55:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PBtkHA008838; Tue, 25 Mar 2003 03:55:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBtf7f008819 for ; Tue, 25 Mar 2003 03:55:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PBtnHP022299 for ; Tue, 25 Mar 2003 03:55:49 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11432 for ; Tue, 25 Mar 2003 03:55:44 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:55:43 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:55:43 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:55:43 Z Received: from c001.snv.cp.net ([209.228.32.134] [209.228.32.134]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:55:42 Z Received: (cpmta 21088 invoked from network); 25 Mar 2003 03:55:41 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.134) with SMTP; 25 Mar 2003 03:55:41 -0800 X-Sent: 25 Mar 2003 11:55:41 GMT Message-Id: <011e01c2f2c5$aa654d80$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <003401c2f2bd$c9d18f10$210d640a@unfix.org> Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 13:57:07 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > IP's should be globably unique. Which will overcome many problems > like network mergers ('oh we need to NAT now'), e2e problems etc. The new address features of IPv6 should resolve this as easily as changing providers. > And it should be quite possible for anybody to use one /64 out of > their /48 for 'printers' and 'microwaves'. Not even talking about > refridgerators full with IPv6 beer (seen that one already :) This means that every SOHO will get a /64? Or every company with 100 employees (make that about 200 nodes)? Done this way we will be defingin IPv7 real quick, as the unused addresses will add up very fast. > I would like to give those appliances globally routable IP space > simply because it would allow my printer to order new paper from > the store when it's almost out. Or better... new beer in my fridge! Yes, or to have the new version of SPAM sent directly to your printer rather than you e-mail or fax. -------------------------------------------------------------------- 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 Mar 25 03:56:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBuN7f008905; Tue, 25 Mar 2003 03:56:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PBuNf3008904; Tue, 25 Mar 2003 03:56:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBuI7f008887 for ; Tue, 25 Mar 2003 03:56:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PBuPcU005440 for ; Tue, 25 Mar 2003 03:56:25 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11660 for ; Tue, 25 Mar 2003 03:56:19 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:56:18 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:56:18 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:56:18 Z Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:56:17 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2PBvkKW011205; Tue, 25 Mar 2003 12:57:46 +0100 (CET) Date: Tue, 25 Mar 2003 12:57:45 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "EricLKlein" From: Kurt Erik Lindqvist In-Reply-To: <010601c2f2c4$2ebdd5e0$67061eac@ttitelecom.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >>>> If you absolutely want NAT take a random address block and NAT it >>>> for >>>> you. You will get the same problems / benefits. >>> >>> Who is going to priovide the registered addresses that will be used >>> for all >>> corporations and at what price? Most companies will not want to have >>> to pay >>> for a public address for all their printers and copiers (and >>> microwaves as >>> those are added by Microsoft). >> >> You can get addresses from your upstream provider. > > Ok, if I understand this from a hardware (not application) point of > view a > company like IBM (or any other large company with multiple sites) will > be > required to pay an upstream provider for (private) local IP addresses > for > their printers. Think about it, at the hardware side of this we are > encouraging them to keep using IPv4 for those items that will not be > connected to the public internet. You pay your provider per traffic volume or bandwidth. Not per IP address. At least non I know of. They will give you as much addresses you need. Now if you still want to put the globally unique addresses behind a NAT, you are free to. But it's a bad idea. The addresses given to you from your provider are not private. - kurtis - -------------------------------------------------------------------- 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 Mar 25 03:59:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBxr7f009204; Tue, 25 Mar 2003 03:59:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PBxrTW009203; Tue, 25 Mar 2003 03:59:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PBxo7f009196 for ; Tue, 25 Mar 2003 03:59:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PBxvcU005936 for ; Tue, 25 Mar 2003 03:59:58 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08396 for ; Tue, 25 Mar 2003 04:59:52 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:59:51 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:59:51 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:59:51 Z Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:59:50 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2PC1JKW011211; Tue, 25 Mar 2003 13:01:20 +0100 (CET) Date: Tue, 25 Mar 2003 13:01:19 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Mike Saywell From: Kurt Erik Lindqvist In-Reply-To: <20030325115319.GI18295@ecs.soton.ac.uk> Message-Id: <7D20E825-5EB9-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This is very true, but there are certain scenarios (like the network > I've > described) where we have a need for a large number of addresses, which > dont require to be globally routable (since network is self-contained). If it is self contained, does it matter what addresses you use? > > If it was possible to use global addresses then I would, however rules > regarding the IPv6 address space allocation make this a near > impossibility > for us. :( What prohibits you from getting an adequate number of addresses? - kurtis - -------------------------------------------------------------------- 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 Mar 25 04:02:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PC2A7f009344; Tue, 25 Mar 2003 04:02:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PC2AVI009343; Tue, 25 Mar 2003 04:02:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PC267f009333 for ; Tue, 25 Mar 2003 04:02:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PC2EcU006601 for ; Tue, 25 Mar 2003 04:02:14 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07743 for ; Tue, 25 Mar 2003 05:02:08 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:02:08 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 11:59:13 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:02:04 Z Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:02:03 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2PC3WKW011214; Tue, 25 Mar 2003 13:03:32 +0100 (CET) Date: Tue, 25 Mar 2003 13:03:31 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "EricLKlein" From: Kurt Erik Lindqvist In-Reply-To: <011e01c2f2c5$aa654d80$67061eac@ttitelecom.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> And it should be quite possible for anybody to use one /64 out of >> their /48 for 'printers' and 'microwaves'. Not even talking about >> refridgerators full with IPv6 beer (seen that one already :) > > This means that every SOHO will get a /64? Or every company with 100 > employees (make that about 200 nodes)? > > Done this way we will be defingin IPv7 real quick, as the unused > addresses > will add up very fast. Uhm, I think you need to go and look at the numbers...:-) The current more or less standard policy is to give out /48s, even to SOHOs. Each host prefix is a /64. >> I would like to give those appliances globally routable IP space >> simply because it would allow my printer to order new paper from >> the store when it's almost out. Or better... new beer in my fridge! > > Yes, or to have the new version of SPAM sent directly to your printer > rather > than you e-mail or fax. > Packet filtering is not the same as NAT. - kurtis - -------------------------------------------------------------------- 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 Mar 25 04:21:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCLY7f010018; Tue, 25 Mar 2003 04:21:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PCLYv1010017; Tue, 25 Mar 2003 04:21:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCLT7f010009 for ; Tue, 25 Mar 2003 04:21:30 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2PCLUK17453; Tue, 25 Mar 2003 13:21:30 +0100 (MET) Date: Tue, 25 Mar 2003 13:17:28 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on the address selection API draft To: Mika Liljeberg Cc: Erik Nordmark , JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= , Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <1048534392.12764.11.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > And if the application specifies both "X" and "not X"? That would be an error. > > An alternate API would be to have one flag per property and always require > a > get before a set. > > I think I would prefer this approach. This is clean, no special cases, > and allows simple checking of system defaults. The application can > always store the default bit vector if it creates multiple sockets. A psychological aspect of such an API is that we need to nail down what the defaults are for all implementations, since application writers might skip invoking the API unless they are going to set some flag. But there is indication that some implementations want to prefer temporary addresses over public addresses, whereas others will follow the default address selection document and do the reverse. So do we make the one bit PREFER_SRC_TMP or PREFER_SRC_PUBLIC? Will applications that have a preference for either always explicitly state it by invoking the API? The psychological benefit of the two flags is that we don't have to choose the default; we can say that any application which has an explicit preference should always invoke the API to state that preference. 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 Mar 25 04:21:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCLe7f010027; Tue, 25 Mar 2003 04:21:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PCLe37010026; Tue, 25 Mar 2003 04:21:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCLX7f010016 for ; Tue, 25 Mar 2003 04:21:34 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2PCLYK17459; Tue, 25 Mar 2003 13:21:34 +0100 (MET) Date: Tue, 25 Mar 2003 13:17:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API To: Francis Dupont Cc: Samita Chakrabarti , Julien.Laganier@Sun.COM, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200303241757.h2OHvmof074401@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => what I propose is not pure per-process control, it is to put the > control in the context of processes. It gives immediatly a per-process > control but with a way to manage the context from applications, it gives > a per-socket control too. Francis, I didn't understand how the per-process context also gives you per-socket control. Are you considering having setsockopts in addition to per-process context controls? Or are you arguing that the setsockopt type of control is not necessary? 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 Mar 25 04:49:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCnN7f010389; Tue, 25 Mar 2003 04:49:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PCnNGJ010388; Tue, 25 Mar 2003 04:49:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCnJ7f010381 for ; Tue, 25 Mar 2003 04:49:19 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PCnRHP002248 for ; Tue, 25 Mar 2003 04:49:27 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03677 for ; Tue, 25 Mar 2003 04:49:21 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:49:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:49:11 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:49:11 Z Received: from c001.snv.cp.net ([209.228.32.139] [209.228.32.139]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:49:10 Z Received: (cpmta 13977 invoked from network); 25 Mar 2003 04:49:08 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 25 Mar 2003 04:49:08 -0800 X-Sent: 25 Mar 2003 12:49:08 GMT Message-Id: <016801c2f2cd$21bae870$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 14:50:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ok, rather than beat a dead horse, let me see if I understand. The following prefixes are no longer going to be valid as there will not be any local addresses Prefixes: · FE8, FE9, FEA, and FEB are Link local addresses · FEC0 is the prefix of a site local address. Site local addresses are the equivalent of a private IPv4 address. · FF02::1 is address that multicasts to all nodes on the LAN. · FF02::2 is address that multicasts to all routers on the LAN. Multicast Prefixes: · ffx1 : node-local, packets never lead the node · ffx2 : link-local, packets are never forwarded by routers (they stay on the link). · ffx5 : site-local, packets never leave the site. · ffx8 : org-local, packets never leave the organization. This are handled by routing protocols. · ffxe : global scope ----- Original Message ----- From: "Kurt Erik Lindqvist" To: "EricLKlein" Cc: Sent: Tuesday, March 25, 2003 2:03 PM Subject: Re: A use for site local addresses? > > > >> And it should be quite possible for anybody to use one /64 out of > >> their /48 for 'printers' and 'microwaves'. Not even talking about > >> refridgerators full with IPv6 beer (seen that one already :) > > > > This means that every SOHO will get a /64? Or every company with 100 > > employees (make that about 200 nodes)? > > > > Done this way we will be defingin IPv7 real quick, as the unused > > addresses > > will add up very fast. > > Uhm, I think you need to go and look at the numbers...:-) > > The current more or less standard policy is to give out /48s, even to > SOHOs. Each host prefix is a /64. > > >> I would like to give those appliances globally routable IP space > >> simply because it would allow my printer to order new paper from > >> the store when it's almost out. Or better... new beer in my fridge! > > > > Yes, or to have the new version of SPAM sent directly to your printer > > rather > > than you e-mail or fax. > > > > Packet filtering is not the same as NAT. > > - kurtis - > > -------------------------------------------------------------------- > 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 Tue Mar 25 04:51:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCpm7f010451; Tue, 25 Mar 2003 04:51:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PCpmUu010450; Tue, 25 Mar 2003 04:51:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCpi7f010443 for ; Tue, 25 Mar 2003 04:51:44 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PCpqHP002742 for ; Tue, 25 Mar 2003 04:51:52 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05737 for ; Tue, 25 Mar 2003 04:51:47 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:50:07 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:50:06 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:50:06 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:50:05 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 148AD8F55; Tue, 25 Mar 2003 13:49:59 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D823A7E25; Tue, 25 Mar 2003 13:49:50 +0100 (CET) From: "Jeroen Massar" To: "'Kurt Erik Lindqvist'" Cc: "'Leif Johansson'" , "'Mark Thompson'" , "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 13:50:51 +0100 Organization: Unfix Message-Id: <004c01c2f2cd$2bf81010$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <8DCA4CE5-5EB8-11D7-B5E2-000393AB1404@kurtis.pp.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] wrote: > On tisdag, mar 25, 2003, at 12:00 Europe/Stockholm, Jeroen > Massar wrote: > > > > > I am also *against* Link local. > > Sure you did not mean site-local? Oops, typo :) Thanks for catching it though :) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 25 04:57:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCvn7f010786; Tue, 25 Mar 2003 04:57:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PCvmZj010785; Tue, 25 Mar 2003 04:57:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PCvj7f010778 for ; Tue, 25 Mar 2003 04:57:45 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PCvrcU017079 for ; Tue, 25 Mar 2003 04:57:53 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09404 for ; Tue, 25 Mar 2003 04:57:47 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:57:47 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:54:55 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:57:46 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:57:46 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 77CEF8F55; Tue, 25 Mar 2003 13:57:44 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id BE35B7E25; Tue, 25 Mar 2003 13:57:38 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 13:58:40 +0100 Organization: Unfix Message-Id: <005401c2f2ce$42ca1580$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <011e01c2f2c5$aa654d80$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PCvj7f010779 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > > IP's should be globably unique. Which will overcome many problems > > like network mergers ('oh we need to NAT now'), e2e problems etc. > > The new address features of IPv6 should resolve this as > easily as changing providers. Well I thought that too at first untill some people who merged big networks clued me in :) > > And it should be quite possible for anybody to use one /64 out of > > their /48 for 'printers' and 'microwaves'. Not even talking about > > refridgerators full with IPv6 beer (seen that one already :) > > This means that every SOHO will get a /64? Or every company with 100 > employees (make that about 200 nodes)? No a /48 per endsite. Or quoting Timothy Love (RIPE) at AIAD: "when in doubt that a endsite will ever get more than one subnet give them a /48" Which boils down to give every endsite a /48, for the ease of administration. Of course one could use one /48 or so for giving out /64's from that. The same as using /64's from your /48 for printers etc.. > Done this way we will be defingin IPv7 real quick, as the > unused addresses will add up very fast. There should be enough, check the HD ratio RFC's. Or Steve Deerings presentation: http://isoc.nl/activ/2002-masterclass-IETF-IPv6.htm > > I would like to give those appliances globally routable IP space > > simply because it would allow my printer to order new paper from > > the store when it's almost out. Or better... new beer in my fridge! > > Yes, or to have the new version of SPAM sent directly to your > printer rather than you e-mail or fax. Never heard of a firewall? Just like normal SPAM you should ACL your relay's, or just don't route certain blocks etc. Remember: NAT is not security but obscurity Greets, Jeroen -------------------------------------------------------------------- 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 Mar 25 05:02:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PD237f011083; Tue, 25 Mar 2003 05:02:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PD22Mg011082; Tue, 25 Mar 2003 05:02:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PD1x7f011074 for ; Tue, 25 Mar 2003 05:01:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PD26HP005013 for ; Tue, 25 Mar 2003 05:02:07 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23770 for ; Tue, 25 Mar 2003 06:02:01 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:02:01 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:02:00 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:02:00 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:02:00 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5A1D58F55; Tue, 25 Mar 2003 14:01:57 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 09D1A7E25; Tue, 25 Mar 2003 14:01:48 +0100 (CET) From: "Jeroen Massar" To: "'Kurt Erik Lindqvist'" , "'EricLKlein'" Cc: Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 14:02:50 +0100 Organization: Unfix Message-Id: <005c01c2f2ce$d7f64160$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PD1x7f011076 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kurt Erik Lindqvist wrote: > > Ok, if I understand this from a hardware (not application) point of > > view a company like IBM (or any other large company with multiple > > sites) will be required to pay an upstream provider for (private) > > local IP addresses for > > their printers. Think about it, at the hardware side of this we are > > encouraging them to keep using IPv4 for those items that will not be > > connected to the public internet. A company like IBM is big enough to have their own global infrastructure and can also get a TLA as they are an ISP for theirselves most probably. Same goes for companies like Microsoft, Apple or non-computer related: Shell for instance. > You pay your provider per traffic volume or bandwidth. Not per IP > address. At least non I know of. They will give you as much addresses > you need. Welll... in IPv6 I do see that coming, fortunatly, as otherwise the complete IPv6 bet for e2e would be futile. In the IPv4 world you actually do pay extra for IP addresses at least as en end-user (home etc :). Fortunatly I do have IPv6 which makes the boxes globaly reachable :) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 25 05:04:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PD4A7f011241; Tue, 25 Mar 2003 05:04:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PD4A3q011240; Tue, 25 Mar 2003 05:04:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PD467f011230 for ; Tue, 25 Mar 2003 05:04:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PD4EHP005628 for ; Tue, 25 Mar 2003 05:04:14 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03678 for ; Tue, 25 Mar 2003 06:04:07 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:04:06 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:04:06 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:04:06 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:04:05 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA07810 for ; Tue, 25 Mar 2003 13:04:04 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA24371 for ; Tue, 25 Mar 2003 12:54:21 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2PCsLW18730 for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 12:54:21 GMT Date: Tue, 25 Mar 2003 12:54:21 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030325125420.GM18295@ecs.soton.ac.uk> References: <20030325115319.GI18295@ecs.soton.ac.uk> <7D20E825-5EB9-11D7-B5E2-000393AB1404@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D20E825-5EB9-11D7-B5E2-000393AB1404@kurtis.pp.se> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 25, 2003 at 01:01:19PM +0100, Kurt Erik Lindqvist wrote: > If it is self contained, does it matter what addresses you use? Sorry that was poorly worded. It's self-contained in that by default there is no default route onto the internet, however some sites may offer free internet access by advertising a second global prefix on their node only. The other option for internet access is via a gateway of some sort, which you connect to using PPPoE etc, and you get a global IP from there. So the addresses we use on the network cant clash with anything outside. > >If it was possible to use global addresses then I would, however rules > >regarding the IPv6 address space allocation make this a near > >impossibility > >for us. :( > > What prohibits you from getting an adequate number of addresses? Well each access point is typically located in someones house, if we go with the recommendations then that's a /48 prefix. So looking to the future we need a large amount of address space, but since it's a community project we dont want to (i.e. can't) pay anything. I should probably be campaigning for community networks in general, so if you want all of these to have global addresses then we're probably into the realms of a /16... If we really wasnt to avoid site-locals then I think the location based addressing I pointed to a while back could be a neat solution, since it gives everybody a block of address space "automatically" and then it's up to the site as to whether it's made globally routable - you'd have to negotiate it with your ISP. I'm probably biased about this though since it ties in with my PhD work... :) Cheers, Mike -------------------------------------------------------------------- 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 Mar 25 05:11:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDAx7f011792; Tue, 25 Mar 2003 05:10:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PDAxKk011791; Tue, 25 Mar 2003 05:10:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDAu7f011784 for ; Tue, 25 Mar 2003 05:10:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PDB4HP006869 for ; Tue, 25 Mar 2003 05:11:04 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17118 for ; Tue, 25 Mar 2003 05:10:58 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:10:54 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:10:54 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:10:54 Z Received: from c001.snv.cp.net ([209.228.32.127] [209.228.32.127]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:10:53 Z Received: (cpmta 13284 invoked from network); 25 Mar 2003 05:10:52 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 25 Mar 2003 05:10:52 -0800 X-Sent: 25 Mar 2003 13:10:52 GMT Message-Id: <018a01c2f2d0$2b01e8e0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <005c01c2f2ce$d7f64160$210d640a@unfix.org> Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 15:12:18 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A company like IBM is big enough to have their own global infrastructure and can also get a TLA as they are an ISP for theirselves most probably. Same goes for companies like Microsoft, Apple or non-computer related: Shell for instance. True, but they will want to keep the private network hardware on their backbone seperate from the public traffic. I suppose that they could take seveal /48's some for internal use and some for customer use. Call me old fassion but it seems a bit much to have that microwave with a registered global address. -------------------------------------------------------------------- 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 Mar 25 05:15:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDFP7f012025; Tue, 25 Mar 2003 05:15:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PDFPl5012022; Tue, 25 Mar 2003 05:15:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDFF7f011992 for ; Tue, 25 Mar 2003 05:15:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PDFNHP007554 for ; Tue, 25 Mar 2003 05:15:23 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20658 for ; Tue, 25 Mar 2003 06:15:17 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:15:17 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:15:17 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:15:16 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:15:16 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08643; Tue, 25 Mar 2003 08:12:56 -0500 (EST) Message-Id: <200303251312.IAA08643@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-flow-label-06.txt Date: Tue, 25 Mar 2003 08:12:56 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-06.txt Pages : 9 Date : 2003-3-24 This document specifies the IPv6 Flow Label field, the requirements for IPv6 source nodes labeling flows, the requirements for IPv6 nodes forwarding labeled packets, and the requirements for flow state establishment methods. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ipv6-flow-label-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-flow-label-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <2003-3-24141426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-flow-label-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-flow-label-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-24141426.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 Tue Mar 25 05:20:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDKW7f012434; Tue, 25 Mar 2003 05:20:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PDKWpE012433; Tue, 25 Mar 2003 05:20:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDKS7f012417 for ; Tue, 25 Mar 2003 05:20:28 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PDKacU022164 for ; Tue, 25 Mar 2003 05:20:36 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21997 for ; Tue, 25 Mar 2003 05:20:30 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:20:30 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:20:30 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:20:30 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:20:29 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id DE0778F57; Tue, 25 Mar 2003 14:20:25 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id EE7C28F48; Tue, 25 Mar 2003 14:20:15 +0100 (CET) From: "Jeroen Massar" To: "'Mike Saywell'" , Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 14:21:17 +0100 Organization: Unfix Message-Id: <006401c2f2d1$6c6cc6f0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030325125420.GM18295@ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PDKS7f012419 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: > On Tue, Mar 25, 2003 at 01:01:19PM +0100, Kurt Erik Lindqvist wrote: > > If it is self contained, does it matter what addresses you use? > > Sorry that was poorly worded. It's self-contained in that by default > there is no default route onto the internet, however some > sites may offer free internet access by advertising a second > global prefix on their node only. > The other option for internet access is via a gateway of some sort, > which you connect to using PPPoE etc, and you get a global IP > from there. So the addresses we use on the network cant clash with > anything outside. Read: Internet IP's are globally unique: get IP's from your upstream. If one defines site-local addresses there are bound to be multiple organizations using the same 'easy to remember' prefixes. Cause thats why some companies also NAT to eachother. Eg company A uses 10.0.0.0/8 and company B has that too. How not handy. One thing which could be done is allowing the registration of say /48's at the RIR's from a pool of address space. But that would match up getting space from your upstream and will only create swamps. > > >If it was possible to use global addresses then I would, > however rules > > >regarding the IPv6 address space allocation make this a near > > >impossibility > > >for us. :( > > > > What prohibits you from getting an adequate number of addresses? > > Well each access point is typically located in someones house, if we > go with the recommendations then that's a /48 prefix. So looking to > the future we need a large amount of address space, but since it's a > community project we dont want to (i.e. can't) pay anything. So you don't pay for the hardware either or the traffic either. Bummer. Get it from an upstream or get a good sponsor. > I should probably be campaigning for community networks in general, so > if you want all of these to have global addresses then we're probably > into the realms of a /16... > > If we really wasnt to avoid site-locals then I think the > location based addressing I pointed to a while back could be a neat > solution, since it gives everybody a block of address space "automatically" and then it's > up to the site as to whether it's made globally routable - you'd have > to negotiate it with your ISP. I'm probably biased about this though > since it ties in with my PhD work... :) What you need is multihoming and you are referring to something known as GFN (Geo For Now). But that has nothing to do with using sitelocals. That's a multihoming issue. This is also apparent as you do not intend to have any upstream of yourselves. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 25 05:28:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDSb7f013144; Tue, 25 Mar 2003 05:28:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PDSbSj013143; Tue, 25 Mar 2003 05:28:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDSX7f013136 for ; Tue, 25 Mar 2003 05:28:33 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PDSfcU024048 for ; Tue, 25 Mar 2003 05:28:41 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26394 for ; Tue, 25 Mar 2003 05:28:35 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:28:35 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:25:43 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:28:35 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:28:32 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 3559B8F57; Tue, 25 Mar 2003 14:28:27 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id BB7528F48; Tue, 25 Mar 2003 14:28:22 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 14:29:25 +0100 Organization: Unfix Message-Id: <006c01c2f2d2$8ddead70$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <018a01c2f2d0$2b01e8e0$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PDSX7f013137 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: I actuall wrote this, but Eric didn't quote correctly: > A company like IBM is big enough to have their own global > infrastructure and can also get a TLA as they are an ISP > for theirselves most probably. Same goes for companies like > Microsoft, Apple or non-computer related: Shell for instance. Then Eric wrote this: > True, but they will want to keep the private network hardware on their > backbone seperate from the public traffic. I suppose that > they could take seveal /48's some for internal use and some > for customer use. They are their own customer, though usually big companies have an internal venture which handles the complete network and where the other business units are customers of that venture. And those venture's know how a firewall work. Quite easy: filter at the edge or as near as possible to the prefixes as possible. I really do not see why this would mean that there even ever would be a need for site-locals. > Call me old fassion but it seems a bit much to have that > microwave with a registered global address. Again: Firewall or don't route it along. Btw... RFC1918 have been leaked onto the global internet too. There was even one stupid (now bankrupt :) company which mailed a certain technical mailinglist at a certain IX and said they where going to announce&use 172.16/16. They claimed it was a stupid joke played onto a newbie. But if somebody actually would, your 'sitelocal' microwave would be reachable. Or do you firewall? :) Greets, Jeroen PS: check RFC1855 or for example a page like: http://www.xs4all.nl/~hanb/documents/quotingguide.html Makes it much clearer who said exactly what. -------------------------------------------------------------------- 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 Mar 25 05:55:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDtn7f013877; Tue, 25 Mar 2003 05:55:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PDtnTN013876; Tue, 25 Mar 2003 05:55:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PDtk7f013869 for ; Tue, 25 Mar 2003 05:55:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PDtrcU028726 for ; Tue, 25 Mar 2003 05:55:53 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21242 for ; Tue, 25 Mar 2003 06:55:48 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:55:38 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:53:57 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:53:57 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:53:56 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA08419 for ; Tue, 25 Mar 2003 13:53:55 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA26768 for ; Tue, 25 Mar 2003 13:47:10 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2PDlAu19481 for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 13:47:10 GMT Date: Tue, 25 Mar 2003 13:47:10 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030325134710.GO18295@ecs.soton.ac.uk> References: <20030325125420.GM18295@ecs.soton.ac.uk> <006401c2f2d1$6c6cc6f0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006401c2f2d1$6c6cc6f0$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 25, 2003 at 02:21:17PM +0100, Jeroen Massar wrote: > What you need is multihoming and you are referring to something known > as GFN (Geo For Now). But that has nothing to do with using sitelocals. > That's a multihoming issue. This is also apparent as you do not intend > to have any upstream of yourselves. Sorry, I was refferring to http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-03.txt, I think it could be considered as a way to distribute quasi-private IP addressses and avoid clashes and thus the need for NATing when networks join. Getting address space from your upstream ISP does not work in every scenario, there should really be some other mechanism for obtaining addresses to experiment with. Mike -------------------------------------------------------------------- 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 Mar 25 06:53:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PErD7f014611; Tue, 25 Mar 2003 06:53:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PErDaV014610; Tue, 25 Mar 2003 06:53:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PErA7f014603 for ; Tue, 25 Mar 2003 06:53:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PErIHP028843 for ; Tue, 25 Mar 2003 06:53:18 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22122 for ; Tue, 25 Mar 2003 07:53:06 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:52:24 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:43:19 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:43:18 Z Received: from klapautius.it.su.se ([130.237.152.81] [130.237.152.81]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:43:18 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2PEeGC02109; Tue, 25 Mar 2003 15:40:27 +0100 Message-Id: <3E806A4F.40800@it.su.se> Date: Tue, 25 Mar 2003 15:40:15 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Saywell CC: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <3E802BDB.1010504@it.su.se> <003401c2f2bd$c9d18f10$210d640a@unfix.org> <20030325115319.GI18295@ecs.soton.ac.uk> In-Reply-To: <20030325115319.GI18295@ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: >I can't really see the motivations to do NAT under v6 when it's so easy >to have multiple addresses on an interface anyway. Joining 2 networks >which use the same address site-local addresses would be nowhere near >as painfull as before since it's that much easier to re-number one of >them under v6. > > Multiple addresses means the application has to choose which to use. This is a non-starter. -------------------------------------------------------------------- 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 Mar 25 06:53:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PErZ7f014621; Tue, 25 Mar 2003 06:53:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PErZkF014620; Tue, 25 Mar 2003 06:53:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PErT7f014613 for ; Tue, 25 Mar 2003 06:53:29 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PErbHP028898 for ; Tue, 25 Mar 2003 06:53:37 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17356 for ; Tue, 25 Mar 2003 06:53:31 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:53:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:53:29 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:53:29 Z Received: from laptop2.kurtis.autonomica.se (laptop2.kurtis.autonomica.se [192.71.80.74]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 14:53:29 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2PEsjKW011291; Tue, 25 Mar 2003 15:54:48 +0100 (CET) Date: Tue, 25 Mar 2003 15:54:40 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: ipng@sunroof.eng.sun.com To: Mike Saywell From: Kurt Erik Lindqvist In-Reply-To: <20030325125420.GM18295@ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On tisdag, mar 25, 2003, at 13:54 Europe/Stockholm, Mike Saywell wrote: > >>> If it was possible to use global addresses then I would, however >>> rules >>> regarding the IPv6 address space allocation make this a near >>> impossibility >>> for us. :( >> >> What prohibits you from getting an adequate number of addresses? > > Well each access point is typically located in someones house, if we > go with the recommendations then that's a /48 prefix. So looking to > the future we need a large amount of address space, but since it's a > community project we dont want to (i.e. can't) pay anything. Well, you still need to pay someone to get to the rest of the Internet, right? There is your source of addresses. - kurtis - -------------------------------------------------------------------- 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 Mar 25 07:01:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PF1c7f014924; Tue, 25 Mar 2003 07:01:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PF1cts014923; Tue, 25 Mar 2003 07:01:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PF1Z7f014916 for ; Tue, 25 Mar 2003 07:01:35 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PF1hcU019402 for ; Tue, 25 Mar 2003 07:01:43 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24300 for ; Tue, 25 Mar 2003 07:01:37 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:01:36 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:01:36 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:01:36 Z Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:01:35 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2PF0xHp020070; Tue, 25 Mar 2003 07:00:59 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA03863; Tue, 25 Mar 2003 15:00:58 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Leif Johansson Cc: Mike Saywell , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? From: Ole Troan Date: Tue, 25 Mar 2003 15:00:58 +0000 In-Reply-To: <3E806A4F.40800@it.su.se> (Leif Johansson's message of "Tue, 25 Mar 2003 15:40:15 +0100") Message-Id: <7t51y0vo5hx.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <3E802BDB.1010504@it.su.se> <003401c2f2bd$c9d18f10$210d640a@unfix.org> <20030325115319.GI18295@ecs.soton.ac.uk> <3E806A4F.40800@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mike Saywell wrote: > >>I can't really see the motivations to do NAT under v6 when it's so easy >>to have multiple addresses on an interface anyway. Joining 2 networks >>which use the same address site-local addresses would be nowhere near >>as painfull as before since it's that much easier to re-number one of >>them under v6. >> > Multiple addresses means the application has to choose which to use. This is > a non-starter. IPv6 has multiple addresses anyway. or do you propose to remove link-locals too? /ot -------------------------------------------------------------------- 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 Mar 25 07:05:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PF517f015100; Tue, 25 Mar 2003 07:05:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PF50af015099; Tue, 25 Mar 2003 07:05:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PF4v7f015086 for ; Tue, 25 Mar 2003 07:04:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PF54cU020361 for ; Tue, 25 Mar 2003 07:05:04 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29472 for ; Tue, 25 Mar 2003 08:04:59 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:04:58 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:04:42 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:04:42 Z Received: from c001.snv.cp.net ([209.228.32.139] [209.228.32.139]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:04:41 Z Received: (cpmta 19139 invoked from network); 25 Mar 2003 07:04:39 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 25 Mar 2003 07:04:39 -0800 X-Sent: 25 Mar 2003 15:04:39 GMT Message-Id: <01be01c2f2e0$105dbd10$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <3E802BDB.1010504@it.su.se> <003401c2f2bd$c9d18f10$210d640a@unfix.org> <20030325115319.GI18295@ecs.soton.ac.uk> <3E806A4F.40800@it.su.se> Subject: Re: A use for site local addresses? Date: Tue, 25 Mar 2003 17:06:05 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I could be wrong here (and apparently it would not be the first time on this topic today) but it appears to me that: The people who are in favor of local addresses are thinking hardware implementation. and The ones against are thinking application functionality. Is there anyone that would be willing to put together a information RFC on this topic explaining why the WG feels that local addresses are wrong, and how to handle both sets of requirements? -------------------------------------------------------------------- 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 Mar 25 07:53:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PFrt7f015762; Tue, 25 Mar 2003 07:53:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PFrtVE015761; Tue, 25 Mar 2003 07:53:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PFrq7f015754 for ; Tue, 25 Mar 2003 07:53:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PFrxcU003353 for ; Tue, 25 Mar 2003 07:54:00 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05025 for ; Tue, 25 Mar 2003 08:53:54 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:53:54 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:53:53 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:53:53 Z Received: from lord.fakat.com (lord.fakat.com [217.208.182.214]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 15:53:52 Z Received: from lord.fakat.com (localhost [127.0.0.1]) by lord.fakat.com (8.12.6/8.12.6) with ESMTP id h2PFrNBv027572; Tue, 25 Mar 2003 16:53:23 +0100 (CET) (envelope-from jasko@lord.fakat.com) Received: from localhost (jasko@localhost) by lord.fakat.com (8.12.6/8.12.6/Submit) with ESMTP id h2PFrNAP027569; Tue, 25 Mar 2003 16:53:23 +0100 (CET) Date: Tue, 25 Mar 2003 16:53:23 +0100 (CET) From: Jasminko Mulahusic To: EricLKlein cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-Reply-To: <01be01c2f2e0$105dbd10$67061eac@ttitelecom.com> Message-Id: <20030325165057.A27558-100000@lord.fakat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 25 Mar 2003, EricLKlein wrote: > I could be wrong here (and apparently it would not be the first time on this > topic today) but it appears to me that: > > The people who are in favor of local addresses are thinking hardware > implementation. just to be clear, we are only talking about getting rid of site-local addresses. not link-local, or other local addresses. jasminko -------------------------------------------------------------------- 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 Mar 25 08:00:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PG0U7f015958; Tue, 25 Mar 2003 08:00:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PG0UfW015957; Tue, 25 Mar 2003 08:00:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PG0Q7f015947 for ; Tue, 25 Mar 2003 08:00:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PG0YcU005321 for ; Tue, 25 Mar 2003 08:00:34 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26661 for ; Tue, 25 Mar 2003 09:00:28 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:00:27 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:00:27 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:00:27 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:00:27 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 2003 08:00:26 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D1B@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLy0DMNXSkApWeASFektKehCnpHBQAFtgNg From: "Michel Py" To: "Mike Saywell" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PG0R7f015948 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > Mike Saywell wrote: > It's self-contained in that by default there is no default > route onto the internet, however some sites may offer free > internet access by advertising a second global prefix on > their node only. The other option for internet access is > via a gateway of some sort, which you connect to using PPPoE > etc, and you get a global IP from there. So the addresses we > use on the network cant clash with anything outside. You are one of the cases why site-locals were designed in the first place. Since this community as chosen the path not to serve your needs you need to adapt. 2002:0A00::/24 is your best bet today. Michel. -------------------------------------------------------------------- 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 Mar 25 08:29:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PGT47f016284; Tue, 25 Mar 2003 08:29:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PGT4Vi016283; Tue, 25 Mar 2003 08:29:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PGT07f016276 for ; Tue, 25 Mar 2003 08:29:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PGT8HP022479 for ; Tue, 25 Mar 2003 08:29:08 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13193 for ; Tue, 25 Mar 2003 09:29:01 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:28:38 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:28:38 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:28:37 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:28:37 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h2PGSPdk116014; Tue, 25 Mar 2003 17:28:29 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2PGSOwU273282; Tue, 25 Mar 2003 17:28:24 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA37042 from ; Tue, 25 Mar 2003 17:28:18 +0100 Message-Id: <3E80835F.1DAA8320@hursley.ibm.com> Date: Tue, 25 Mar 2003 17:27:11 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: EricLKlein Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <005c01c2f2ce$d7f64160$210d640a@unfix.org> <018a01c2f2d0$2b01e8e0$67061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, I can't speak for IBM's IS people, but we have been splitting Net 9 between internal and external use for many years, without spamming the entire Internet looking for printers. There is no reason we would do anything different with an IPv6 prefix. It's a simple enough matter of scoping and configuration. On a "legal" point, the chairs promised to test the WG consensus to deprecate site local on this list. The strong consensus in the room last week isn't definitive; it's the consensus (or oetherwise) on this list that counts. Brian EricLKlein wrote: > > A company like IBM is big enough to have their own global > infrastructure and can also get a TLA as they are an ISP > for theirselves most probably. Same goes for companies like > Microsoft, Apple or non-computer related: Shell for instance. > > True, but they will want to keep the private network hardware on their > backbone seperate from the public traffic. I suppose that they could take > seveal /48's some for internal use and some for customer use. > > Call me old fassion but it seems a bit much to have that microwave with a > registered global address. -------------------------------------------------------------------- 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 Mar 25 08:58:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PGwF7f016816; Tue, 25 Mar 2003 08:58:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PGwFUS016815; Tue, 25 Mar 2003 08:58:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PGwB7f016808 for ; Tue, 25 Mar 2003 08:58:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PGwJHP000785 for ; Tue, 25 Mar 2003 08:58:19 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27792 for ; Tue, 25 Mar 2003 09:57:32 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:57:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:57:28 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:57:28 Z Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 16:57:27 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2PGvO33085880 for ; Tue, 25 Mar 2003 17:57:24 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2PGvOwU285886 for ; Tue, 25 Mar 2003 17:57:24 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44716 from ; Tue, 25 Mar 2003 17:57:22 +0100 Message-Id: <3E808A2F.7837A9C3@hursley.ibm.com> Date: Tue, 25 Mar 2003 17:56:15 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <3E802BDB.1010504@it.su.se> <003401c2f2bd$c9d18f10$210d640a@unfix.org> <20030325115319.GI18295@ecs.soton.ac.uk> <3E806A4F.40800@it.su.se> <7t51y0vo5hx.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole Troan wrote: > > > Mike Saywell wrote: > > > >>I can't really see the motivations to do NAT under v6 when it's so easy > >>to have multiple addresses on an interface anyway. Joining 2 networks > >>which use the same address site-local addresses would be nowhere near > >>as painfull as before since it's that much easier to re-number one of > >>them under v6. > >> > > Multiple addresses means the application has to choose which to use. This is > > a non-starter. > > IPv6 has multiple addresses anyway. or do you propose to remove > link-locals too? Multiple addresses per host are a real-world feature of IPv4 and have always been a design goal of IPv6. We've already defined the default address selection algorithm (RFC 3484). Applications are welcome to use a different algorithm, but they don't need to, which is why the default was defined. (RFC 3484 will need touching up, if we confirm the deprecation of site-local.) Brian -------------------------------------------------------------------- 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 Mar 25 10:14:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIEwVV017365; Tue, 25 Mar 2003 10:14:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIEvNA017364; Tue, 25 Mar 2003 10:14:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIErVV017357 for ; Tue, 25 Mar 2003 10:14:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIF1HP028862 for ; Tue, 25 Mar 2003 10:15:01 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25217 for ; Tue, 25 Mar 2003 11:14:55 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:06:18 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:01:58 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:01:58 Z Received: from roll.mentat.com (roll.mentat.com [192.88.122.129]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:01:57 Z Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2PI20522244; Tue, 25 Mar 2003 10:02:00 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2PI21A28967; Tue, 25 Mar 2003 10:02:01 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA19136; Tue, 25 Mar 2003 10:07:40 -0800 (PST) Date: Tue, 25 Mar 2003 10:07:40 -0800 (PST) From: Tim Hartrick Message-Id: <200303251807.KAA19136@feller.mentat.com> To: eric@mehr.ws, kurtis@kurtis.pp.se Subject: Re: A use for site local addresses? Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > You pay your provider per traffic volume or bandwidth. Not per IP > address. At least non I know of. They will give you as much addresses > you need. Now if you still want to put the globally unique addresses > behind a NAT, you are free to. But it's a bad idea. The addresses given > to you from your provider are not private. > I know of almost no US providers that don't currently charge for IPv4 address space. Absent some regulation, there is no reason to believe that they will stop charging for IPv6 address space no matter how freely the bits are made available to them. It would be great if ISPs would charge for bandwidth only but that simply isn't the way the world currently works and there is absolutely nothing about IPv6 that will change that. More bits in the address don't mean diddly if the only way to get the bits is through an oligarchy of ISPs. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- 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 Mar 25 10:33:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIXNVV017769; Tue, 25 Mar 2003 10:33:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIXNKW017768; Tue, 25 Mar 2003 10:33:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIXJVV017761 for ; Tue, 25 Mar 2003 10:33:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIXRcU028161 for ; Tue, 25 Mar 2003 10:33:27 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14055 for ; Tue, 25 Mar 2003 10:33:21 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:32:22 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:32:21 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:32:21 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:32:20 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 270D08F67; Tue, 25 Mar 2003 19:32:17 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 264518F10; Tue, 25 Mar 2003 19:32:11 +0100 (CET) From: "Jeroen Massar" To: "'Tim Hartrick'" Cc: Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 19:33:13 +0100 Organization: Unfix Message-Id: <007601c2f2fc$ff5e84a0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <200303251807.KAA19136@feller.mentat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PIXJVV017762 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Hartrick wrote: > All, > > > > > You pay your provider per traffic volume or bandwidth. Not per IP > > address. At least non I know of. They will give you as much addresses > > you need. Now if you still want to put the globally unique addresses > > behind a NAT, you are free to. But it's a bad idea. The addresses given > > to you from your provider are not private. > > > > I know of almost no US providers that don't currently charge > for IPv4 address space. Enduser ISP's will always charge for extra IP space as it's currently not customary to give an enduser more than 1 IP. Also IPv4 is a becoming a 'scarce' resource. > Absent some regulation, there is no reason to believe that > they will stop charging for IPv6 address space no matter > how freely the bits are made available to them. > It would be great if ISPs would charge for bandwidth > only but that simply isn't the way the world currently works > and there is absolutely nothing about IPv6 that will change that. > More bits in the address don't mean diddly if the only way to > get the bits is through an oligarchy of ISPs. If the ISP doesn't provide /48's to an endsite, other ISP's will have the advantage that they do. Also if the ISP doesn't they are going against RFC's. You might also realize that the current TLA policy for RIR's demands that you have 200 prospect clients. That is 200x /48. Aka 200 endusers on DSL will suffice for them. Currently even most tunnelbroker system endusers get a /48 and in some cases even more. And they are not even paying for bandwidth nor for ipspace. Go figure ;) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 25 10:36:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIadVV017853; Tue, 25 Mar 2003 10:36:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIadC5017852; Tue, 25 Mar 2003 10:36:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIaZVV017842 for ; Tue, 25 Mar 2003 10:36:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIahHP008416 for ; Tue, 25 Mar 2003 10:36:43 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25396 for ; Tue, 25 Mar 2003 11:36:37 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:36:33 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:36:33 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:36:33 Z Received: from laptop2.kurtis.autonomica.se ([195.43.225.70] [195.43.225.70]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:36:32 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2PIbdKW011415; Tue, 25 Mar 2003 19:37:40 +0100 (CET) Date: Tue, 25 Mar 2003 19:37:38 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: eric@mehr.ws, ipng@sunroof.eng.sun.com To: Tim Hartrick From: Kurt Erik Lindqvist In-Reply-To: <200303251807.KAA19136@feller.mentat.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I know of almost no US providers that don't currently charge for IPv4 > address > space. Absent some regulation, there is no reason to believe that > they will > stop charging for IPv6 address space no matter how freely the bits are > made > available to them. It would be great if ISPs would charge for > bandwidth > only but that simply isn't the way the world currently works and there > is > absolutely nothing about IPv6 that will change that. More bits in the > address > don't mean diddly if the only way to get the bits is through an > oligarchy > of ISPs. This probably comes down to the ARIN membership. Not all the world get their IP addresses from ARIN though...and for IPv6 most people don't. - kurtis - -------------------------------------------------------------------- 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 Mar 25 10:43:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIhnVV018216; Tue, 25 Mar 2003 10:43:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIhnKv018215; Tue, 25 Mar 2003 10:43:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIhjVV018199 for ; Tue, 25 Mar 2003 10:43:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIhrcU002335 for ; Tue, 25 Mar 2003 10:43:53 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28958 for ; Tue, 25 Mar 2003 11:43:47 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:42:52 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:39:47 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:42:38 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:42:37 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2PIhFwY005503; Tue, 25 Mar 2003 20:43:15 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2PIh7DH005502; Tue, 25 Mar 2003 20:43:07 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: DAD in node requirements draft From: Mika Liljeberg To: itojun@iijlab.net Cc: kuntal@iqmail.net, ipng@sunroof.eng.sun.com In-Reply-To: <20030325022739.3560E4B22@coconut.itojun.org> References: <20030325022739.3560E4B22@coconut.itojun.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048617786.12768.18.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 20:43:07 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-03-25 at 04:27, itojun@iijlab.net wrote: > it makes more sense when rules are simpler. if you always perform DAD > you can always ensure there's no duplicate. even if machine A is > autoconfigured with prefix P::/64 and DAD-safe link-local address > fe80::ID, the other end could configure P:ID intentionally. It would be more efficient to always do DAD with the link-local prefix rather than full address, and just ensure that each IID is owned by a single machine. I.e., if you configure P:ID, do dad with FE80:ID (unless already done) and defend all X:ID. MikaL -------------------------------------------------------------------- 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 Mar 25 10:49:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PInaVV018490; Tue, 25 Mar 2003 10:49:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PInalq018489; Tue, 25 Mar 2003 10:49:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PInWVV018479 for ; Tue, 25 Mar 2003 10:49:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIneHP013566 for ; Tue, 25 Mar 2003 10:49:40 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27544 for ; Tue, 25 Mar 2003 10:49:34 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:49:34 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:49:34 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:49:33 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:49:33 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 25 Mar 2003 10:49:28 -0800 Reply-To: From: "Tony Hain" To: "'Kurt Erik Lindqvist'" , "'EricLKlein'" Cc: Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 10:49:27 -0800 Message-Id: <03ec01c2f2ff$432bee50$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <751C3918-5EA0-11D7-B5E2-000393AB1404@kurtis.pp.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site-locals was voted down in the WG meeting in SF. The IETF doesn't vote ... and there is no way a decision gets made in a meeting. It doesn't matter that a few vocal people want to remove a capability because they don't understand it, the rules of the IETF are that decisions are based on mail list discussions. Site-locals are useful exactly for the case that started this thread, though 6to4 from the public side of each nat would also work. They are also useful for the intermittent connected network, because internal connections are not dropped at every connect event. Those applications that are concerned about the potential of breaking have a clearly defined prefix to avoid using. Tony -------------------------------------------------------------------- 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 Mar 25 10:54:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIsVVV018694; Tue, 25 Mar 2003 10:54:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIsVF9018692; Tue, 25 Mar 2003 10:54:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIsSVV018685 for ; Tue, 25 Mar 2003 10:54:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIsZHP015509 for ; Tue, 25 Mar 2003 10:54:35 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00435 for ; Tue, 25 Mar 2003 11:54:30 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:54:29 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Tue, 25 Mar 2003 18:54:29 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP; Tue, 25 Mar 2003 18:54:28 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay1.sun.com with ESMTP; Tue, 25 Mar 2003 18:54:27 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2PItFwY005559; Tue, 25 Mar 2003 20:55:15 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2PItDBW005558; Tue, 25 Mar 2003 20:55:13 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: comments on the address selection API draft From: Mika Liljeberg To: Erik Nordmark Cc: JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= , Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048618512.12765.29.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 20:55:13 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-03-25 at 14:17, Erik Nordmark wrote: > > And if the application specifies both "X" and "not X"? > > That would be an error. Exactly. The kernel needs to test this and return an error ==> bloat. > So do we make the one bit PREFER_SRC_TMP or PREFER_SRC_PUBLIC? PUBLIC is the obvious default since that is the current expected behaviour, although the system administrator might decide to change it. > Will applications that have a preference for either always explicitly state it > by invoking the API? They should. The system default might be configurable by the admin so the apps can't rely on a particular default. > The psychological benefit of the two flags is that we don't have to choose > the default; we can say that any application which has an explicit preference > should always invoke the API to state that preference. I don't follow. This is true regardless of whether there is one bit or two. If an application doesn't care, it doesn't invoke the API at all. MikaL -------------------------------------------------------------------- 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 Mar 25 10:56:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIu1VV018761; Tue, 25 Mar 2003 10:56:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIu1Vp018760; Tue, 25 Mar 2003 10:56:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PItvVV018750 for ; Tue, 25 Mar 2003 10:55:57 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIu5HP016039 for ; Tue, 25 Mar 2003 10:56:05 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03075 for ; Tue, 25 Mar 2003 10:56:00 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:55:59 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:55:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:55:59 Z Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:55:58 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2PItq9a007543; Tue, 25 Mar 2003 10:55:53 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA13722; Tue, 25 Mar 2003 18:55:51 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Mika Liljeberg Cc: itojun@iijlab.net, kuntal@iqmail.net, ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft From: Ole Troan Date: Tue, 25 Mar 2003 18:55:51 +0000 In-Reply-To: <1048617786.12768.18.camel@devil> (Mika Liljeberg's message of "25 Mar 2003 20:43:07 +0200") Message-Id: <7t51y0vi8co.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <20030325022739.3560E4B22@coconut.itojun.org> <1048617786.12768.18.camel@devil> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika, >> it makes more sense when rules are simpler. if you always perform DAD >> you can always ensure there's no duplicate. even if machine A is >> autoconfigured with prefix P::/64 and DAD-safe link-local address >> fe80::ID, the other end could configure P:ID intentionally. > > It would be more efficient to always do DAD with the link-local prefix > rather than full address, and just ensure that each IID is owned by a > single machine. I.e., if you configure P:ID, do dad with FE80:ID (unless > already done) and defend all X:ID. sure, but that wouldn't allow different nodes using the same IID with different prefix. note the mechanism is called DAD not DIID. this has been discussed to death numerous times, please refer to the archive. /ot -------------------------------------------------------------------- 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 Mar 25 10:57:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIvRVV018872; Tue, 25 Mar 2003 10:57:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIvRlM018870; Tue, 25 Mar 2003 10:57:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIvNVV018863 for ; Tue, 25 Mar 2003 10:57:23 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIvVcU007831 for ; Tue, 25 Mar 2003 10:57:31 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29143 for ; Tue, 25 Mar 2003 10:57:26 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:57:25 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:54:33 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:57:25 Z Received: from TheWorld.com ([199.172.62.103] [199.172.62.103]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:57:24 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8/8.12.8) with ESMTP id h2PIvIvU022234; Tue, 25 Mar 2003 13:57:18 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id NAA6652798; Tue, 25 Mar 2003 13:57:12 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 25 Mar 2003 13:57:12 -0500 From: Quality Quorum To: Kurt Erik Lindqvist cc: EricLKlein , Subject: Re: A use for site local addresses? In-Reply-To: <751C3918-5EA0-11D7-B5E2-000393AB1404@kurtis.pp.se> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 25 Mar 2003, Kurt Erik Lindqvist wrote: > The same people are also trying to understand why a number of > applications doesn't work in their network and how come that trojan > send their password file to a unknown destination. Private addresses > comes at a cost that is becoming more and more apparent. No need to pay > that price in IPv6 as well as in IPv4. You can uniquely map each and every local address to a combination of a single /64 + 64-bit unique id. So, organizations who care can have static mapping. > > If you absolutely want NAT take a random address block and NAT it for > you. You will get the same problems / benefits. It would be nice to know that this block is not used for something else. > > Site-locals was voted down in the WG meeting in SF. > > - kurtis - > -------------------------------------------------------------------- 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 Mar 25 10:57:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIvdVV018899; Tue, 25 Mar 2003 10:57:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PIvdSx018898; Tue, 25 Mar 2003 10:57:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PIvVVV018885 for ; Tue, 25 Mar 2003 10:57:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PIvdcU007881 for ; Tue, 25 Mar 2003 10:57:39 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29242 for ; Tue, 25 Mar 2003 10:57:33 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:57:33 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:54:41 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:57:32 Z Received: from roll.mentat.com (roll.mentat.com [192.88.122.129]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 18:57:32 Z Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2PIve522691; Tue, 25 Mar 2003 10:57:40 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2PIveA02352; Tue, 25 Mar 2003 10:57:40 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA19148; Tue, 25 Mar 2003 11:03:20 -0800 (PST) Date: Tue, 25 Mar 2003 11:03:20 -0800 (PST) From: Tim Hartrick Message-Id: <200303251903.LAA19148@feller.mentat.com> To: jeroen@unfix.org Subject: RE: A use for site local addresses? Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen, > > Enduser ISP's will always charge for extra IP space as it's > currently not customary to give an enduser more than 1 IP. > Also IPv4 is a becoming a 'scarce' resource. > And what precisely we change this custom for IPv6? Quoting RFCs is silly in the face MBAs motivated by profit is folly. > > Absent some regulation, there is no reason to believe that > > they will stop charging for IPv6 address space no matter > > how freely the bits are made available to them. > > It would be great if ISPs would charge for bandwidth > > only but that simply isn't the way the world currently works > > and there is absolutely nothing about IPv6 that will change that. > > More bits in the address don't mean diddly if the only way to > > get the bits is through an oligarchy of ISPs. > > If the ISP doesn't provide /48's to an endsite, other ISP's > will have the advantage that they do. Also if the ISP doesn't > they are going against RFC's. > RFCs fall regularly in the face of the profit motive. > You might also realize that the current TLA policy for RIR's > demands that you have 200 prospect clients. That is 200x /48. > Aka 200 endusers on DSL will suffice for them. > > Currently even most tunnelbroker system endusers get > a /48 and in some cases even more. And they are not even > paying for bandwidth nor for ipspace. Go figure ;) > I have little faith that the current state of affairs will resemble the eventual state of affairs. No one currently expects to make money from IPv6. Once they do, address space will become a profit center. MBAs don't care about RFCs. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- 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 Mar 25 11:07:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJ7KVV020000; Tue, 25 Mar 2003 11:07:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PJ7Kqh019999; Tue, 25 Mar 2003 11:07:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJ7GVV019992 for ; Tue, 25 Mar 2003 11:07:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PJ7OcU012465 for ; Tue, 25 Mar 2003 11:07:24 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07752 for ; Tue, 25 Mar 2003 11:07:19 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:07:18 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:07:18 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:07:18 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:07:17 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2PJ7owY005631; Tue, 25 Mar 2003 21:07:51 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2PJ7mWi005630; Tue, 25 Mar 2003 21:07:48 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: DAD in node requirements draft From: Mika Liljeberg To: Ole Troan Cc: itojun@iijlab.net, kuntal@iqmail.net, ipng@sunroof.eng.sun.com In-Reply-To: <7t51y0vi8co.fsf@mrwint.cisco.com> References: <20030325022739.3560E4B22@coconut.itojun.org> <1048617786.12768.18.camel@devil> <7t51y0vi8co.fsf@mrwint.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048619267.12768.34.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 21:07:48 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2003-03-25 at 20:55, Ole Troan wrote: > > It would be more efficient to always do DAD with the link-local prefix > > rather than full address, and just ensure that each IID is owned by a > > single machine. I.e., if you configure P:ID, do dad with FE80:ID (unless > > already done) and defend all X:ID. > > sure, but that wouldn't allow different nodes using the same IID with > different prefix. This is not recommended, anyway. > note the mechanism is called DAD not DIID. this has > been discussed to death numerous times, please refer to the archive. I know. Means people still disagree about it. MikaL -------------------------------------------------------------------- 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 Mar 25 11:12:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJCjVV020240; Tue, 25 Mar 2003 11:12:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PJCjGj020239; Tue, 25 Mar 2003 11:12:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJCgVV020232 for ; Tue, 25 Mar 2003 11:12:42 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PJCocU014552 for ; Tue, 25 Mar 2003 11:12:50 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11966 for ; Tue, 25 Mar 2003 11:12:44 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:12:43 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:12:43 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:12:43 Z Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:12:43 Z Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PJCHc28467; Tue, 25 Mar 2003 13:12:17 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 13:12:17 -0600 Message-Id: <1B54FA3A2709D51195C800508BF9386A080B37E3@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Ole Troan'" , Mika Liljeberg Cc: itojun@iijlab.net, kuntal@iqmail.net, ipng@sunroof.eng.sun.com Subject: RE: DAD in node requirements draft Date: Tue, 25 Mar 2003 13:12:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F302.72F89C98" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F302.72F89C98 Content-Type: text/plain; charset="iso-8859-1" Hi, Right, there are always privacy address extensions ((RFC 3041). But the original question related to PPP links. During 3GPP (UMTS) work on PDP context activation, it was agreed to make the /64 prefix unique per primary (and associated secondary) PDP contexts so that DAD would not have to be performed (particularly since privacy addresses are specified for use in 3GPP). See RFC 3314 and, I believe, 3G TS 23.060 (and/or maybe another document in the 3GPP 24 series). 3GPP2 (cdma2000) uses PPP and not a PDP context. In IS-835-B it is stated that the /64 prefix(es) must be unique to that PPP link ... again avoiding DAD when privacy addresses are used. Since the IETF IPv6 WG is in the process of updating the IPv6 PPP RFC 2472 (more specifically IPV6CP), my question is: What changes are being planned to that RFC? Do any of these changes pertain to the granularity/uniqueness of the /64 prefix? Thanks. Regards, Pete -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: Tuesday, March 25, 2003 12:56 PM To: Mika Liljeberg Cc: itojun@iijlab.net; kuntal@iqmail.net; ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft Mika, >> it makes more sense when rules are simpler. if you always perform DAD >> you can always ensure there's no duplicate. even if machine A is >> autoconfigured with prefix P::/64 and DAD-safe link-local address >> fe80::ID, the other end could configure P:ID intentionally. > > It would be more efficient to always do DAD with the link-local prefix > rather than full address, and just ensure that each IID is owned by a > single machine. I.e., if you configure P:ID, do dad with FE80:ID (unless > already done) and defend all X:ID. sure, but that wouldn't allow different nodes using the same IID with different prefix. note the mechanism is called DAD not DIID. this has been discussed to death numerous times, please refer to the archive. /ot -------------------------------------------------------------------- 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 -------------------------------------------------------------------- ------_=_NextPart_001_01C2F302.72F89C98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DAD in node requirements draft

Hi,

Right, there are always privacy address extensions = ((RFC 3041).

But the original question related to PPP = links.

During 3GPP (UMTS) work on PDP context activation, it = was agreed to make the /64 prefix unique per primary (and associated = secondary) PDP contexts so that DAD would not have to be performed = (particularly since privacy addresses are specified for use in 3GPP). = See RFC 3314 and, I believe, 3G TS 23.060 (and/or maybe another = document in the 3GPP 24 series).

3GPP2 (cdma2000) uses PPP and not a PDP context. In = IS-835-B it is stated that the /64 prefix(es) must be unique to that = PPP link ... again avoiding DAD when privacy addresses are = used.

Since the IETF IPv6 WG is in the process of updating = the IPv6 PPP RFC 2472 (more specifically IPV6CP), my question is: What = changes are being planned to that RFC? Do any of these changes pertain = to the granularity/uniqueness of the /64 prefix? Thanks.

Regards,

Pete

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]
Sent: Tuesday, March 25, 2003 12:56 PM
To: Mika Liljeberg
Cc: itojun@iijlab.net; kuntal@iqmail.net; = ipng@sunroof.eng.sun.com
Subject: Re: DAD in node requirements draft


Mika,

>>      it makes more sense = when rules are simpler.  if you always perform DAD
>>      you can always = ensure there's no duplicate.  even if machine A is
>>      autoconfigured = with prefix P::/64 and DAD-safe link-local address
>>      fe80::ID, the = other end could configure P:ID intentionally.
>
> It would be more efficient to always do DAD = with the link-local prefix
> rather than full address, and just ensure that = each IID is owned by a
> single machine. I.e., if you configure P:ID, do = dad with FE80:ID (unless
> already done) and defend all X:ID.

sure, but that wouldn't allow different nodes using = the same IID with
different prefix. note the mechanism is called DAD = not DIID. this has
been discussed to death numerous times, please refer = to the archive.

/ot
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C2F302.72F89C98-- -------------------------------------------------------------------- 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 Mar 25 11:14:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJElVV020382; Tue, 25 Mar 2003 11:14:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PJEk0K020381; Tue, 25 Mar 2003 11:14:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJEgVV020371 for ; Tue, 25 Mar 2003 11:14:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PJEoHP023877 for ; Tue, 25 Mar 2003 11:14:50 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04684 for ; Tue, 25 Mar 2003 12:14:41 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:14:40 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:14:40 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:14:40 Z Received: from roll.mentat.com (roll.mentat.com [192.88.122.129]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:14:39 Z Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2PJEs522791; Tue, 25 Mar 2003 11:14:55 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.11.6+Sun/8.11.6+Mentat) with ESMTP id h2PJEtA03081; Tue, 25 Mar 2003 11:14:55 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA19153; Tue, 25 Mar 2003 11:20:34 -0800 (PST) Date: Tue, 25 Mar 2003 11:20:34 -0800 (PST) From: Tim Hartrick Message-Id: <200303251920.LAA19153@feller.mentat.com> To: jeroen@unfix.org Subject: RE: A use for site local addresses? Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen, Lets try that again. The first attempt wasn't English. Hopefully this will at least resemble English. > > Enduser ISP's will always charge for extra IP space as it's > currently not customary to give an enduser more than 1 IP. > Also IPv4 is a becoming a 'scarce' resource. > And what precisely will change this custom for IPv6? Quoting RFCs is silly in the face of MBAs motivated by profit. It is folly. > > Absent some regulation, there is no reason to believe that > > they will stop charging for IPv6 address space no matter > > how freely the bits are made available to them. > > It would be great if ISPs would charge for bandwidth > > only but that simply isn't the way the world currently works > > and there is absolutely nothing about IPv6 that will change that. > > More bits in the address don't mean diddly if the only way to > > get the bits is through an oligarchy of ISPs. > > If the ISP doesn't provide /48's to an endsite, other ISP's > will have the advantage that they do. Also if the ISP doesn't > they are going against RFC's. > RFCs fall regularly in the face of the profit motive. > You might also realize that the current TLA policy for RIR's > demands that you have 200 prospect clients. That is 200x /48. > Aka 200 endusers on DSL will suffice for them. > > Currently even most tunnelbroker system endusers get > a /48 and in some cases even more. And they are not even > paying for bandwidth nor for ipspace. Go figure ;) > I have little faith that the current state of affairs will resemble the eventual state of affairs. No one currently expects to make money from IPv6. Once they do, address space will become a profit center. MBAs don't care about RFCs. Don't get me wrong I don't mind ISPs making a profit. If they don't I won't have service but that doesn't mean that every small and medium size business that can't pass itself off as an ISP should have their internal topology held hostage by the local oligopoly of ISPs. Small and medium sized businesses simply won't accept that cost risk and will promptly move to using NAT to protect themselves from renumbering and/or cost uncertainty. They can't really be expected to do anything else given IPv4's history of real and manufactured address scarcity. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- 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 Mar 25 11:26:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJQpVV021068; Tue, 25 Mar 2003 11:26:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PJQpGp021067; Tue, 25 Mar 2003 11:26:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJQmVV021057 for ; Tue, 25 Mar 2003 11:26:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PJQtcU019915 for ; Tue, 25 Mar 2003 11:26:55 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26321 for ; Tue, 25 Mar 2003 12:26:50 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:26:49 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:26:49 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:26:48 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:26:48 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id ABD79137F0A; Tue, 25 Mar 2003 11:26:46 -0800 (PST) Date: Tue, 25 Mar 2003 11:26:46 -0800 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "EricLKlein" From: David Conrad In-Reply-To: <011e01c2f2c5$aa654d80$67061eac@ttitelecom.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, On Tuesday, March 25, 2003, at 03:57 AM, EricLKlein wrote: >> IP's should be globably unique. Which will overcome many problems >> like network mergers ('oh we need to NAT now'), e2e problems etc. > The new address features of IPv6 should resolve this as easily as > changing > providers. What features are those? > This means that every SOHO will get a /64? Or every company with 100 > employees (make that about 200 nodes)? > > Done this way we will be defingin IPv7 real quick, as the unused > addresses > will add up very fast. There are a _lot_ of IPv6 routing prefixes, namely 281,474,976,710,656 (assuming every allocation is a /48 as is the current plan (last I heard)). Right now, there are about 120K routing prefixes in the Internet. I think IPv7 is a ways off. Rgds, -drc -------------------------------------------------------------------- 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 Mar 25 11:29:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJThVV021142; Tue, 25 Mar 2003 11:29:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PJThsj021141; Tue, 25 Mar 2003 11:29:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PJTeVV021134 for ; Tue, 25 Mar 2003 11:29:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PJTmcU020881 for ; Tue, 25 Mar 2003 11:29:48 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24643 for ; Tue, 25 Mar 2003 11:29:42 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:29:41 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:29:41 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:29:41 Z Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 19:29:41 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2PJTFHp012302; Tue, 25 Mar 2003 11:29:15 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA15251; Tue, 25 Mar 2003 19:29:14 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Peter Barany" Cc: Mika Liljeberg , itojun@iijlab.net, kuntal@iqmail.net, ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft From: Ole Troan Date: Tue, 25 Mar 2003 19:29:14 +0000 In-Reply-To: <1B54FA3A2709D51195C800508BF9386A080B37E3@zrc2c000.us.nortel.com> ("Peter Barany"'s message of "Tue, 25 Mar 2003 13:12:16 -0600") Message-Id: <7t5y933gs8l.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <1B54FA3A2709D51195C800508BF9386A080B37E3@zrc2c000.us.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [...] > During 3GPP (UMTS) work on PDP context activation, it was agreed to make the > /64 prefix unique per primary (and associated secondary) PDP contexts so > that DAD would not have to be performed (particularly since privacy > addresses are specified for use in 3GPP). See RFC 3314 and, I believe, 3G TS > 23.060 (and/or maybe another document in the 3GPP 24 series). > > 3GPP2 (cdma2000) uses PPP and not a PDP context. In IS-835-B it is stated > that the /64 prefix(es) must be unique to that PPP link ... again avoiding > DAD when privacy addresses are used. requiring that a /64 is unique on a link does not avoid DAD. doesn't the 3GPP specs restrict one end of the link to not use any addresses from the prefix, if so DAD is not needed. > Since the IETF IPv6 WG is in the process of updating the IPv6 PPP RFC 2472 > (more specifically IPV6CP), my question is: What changes are being planned > to that RFC? Do any of these changes pertain to the granularity/uniqueness > of the /64 prefix? Thanks. the only thing I can see requiring an update is that the value of DupAddrDetectTransmits should default to 1 not 0. you can turn off DAD in your environment if you know you don't need it. /ot -------------------------------------------------------------------- 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 Mar 25 12:05:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PK5IVV021839; Tue, 25 Mar 2003 12:05:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PK5Ipr021838; Tue, 25 Mar 2003 12:05:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PK5EVV021831 for ; Tue, 25 Mar 2003 12:05:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PK5MHP012152 for ; Tue, 25 Mar 2003 12:05:22 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02740 for ; Tue, 25 Mar 2003 13:05:16 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:05:12 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:05:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:05:11 Z Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:05:10 Z Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PK4Jc16329; Tue, 25 Mar 2003 14:04:19 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 14:04:19 -0600 Message-Id: <1B54FA3A2709D51195C800508BF9386A080B37E5@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Ole Troan'" Cc: Mika Liljeberg , itojun@iijlab.net, kuntal@iqmail.net, ipng@sunroof.eng.sun.com Subject: RE: DAD in node requirements draft Date: Tue, 25 Mar 2003 14:04:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F309.B3B8948E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F309.B3B8948E Content-Type: text/plain; charset="iso-8859-1" There may be some terminology/semantics that need to be clarified regarding my usage of the term "link". What I meant to convey was that for 3GPP (UMTS), a primary PDP context (and its associated secondary PDP contexts) are treated as a single IPv6 "link". But the GGSN views each primary PDP context as a single "subnet". Therefore, DAD is not required. Similar for 3GPP2 (cdma2000), except PPP is used, etc. Pete -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: Tuesday, March 25, 2003 1:29 PM To: Barany, Peter [RICH1:2H16:EXCH] Cc: Mika Liljeberg; itojun@iijlab.net; kuntal@iqmail.net; ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft [...] > During 3GPP (UMTS) work on PDP context activation, it was agreed to make the > /64 prefix unique per primary (and associated secondary) PDP contexts so > that DAD would not have to be performed (particularly since privacy > addresses are specified for use in 3GPP). See RFC 3314 and, I believe, 3G TS > 23.060 (and/or maybe another document in the 3GPP 24 series). > > 3GPP2 (cdma2000) uses PPP and not a PDP context. In IS-835-B it is stated > that the /64 prefix(es) must be unique to that PPP link ... again avoiding > DAD when privacy addresses are used. requiring that a /64 is unique on a link does not avoid DAD. doesn't the 3GPP specs restrict one end of the link to not use any addresses from the prefix, if so DAD is not needed. > Since the IETF IPv6 WG is in the process of updating the IPv6 PPP RFC 2472 > (more specifically IPV6CP), my question is: What changes are being planned > to that RFC? Do any of these changes pertain to the granularity/uniqueness > of the /64 prefix? Thanks. the only thing I can see requiring an update is that the value of DupAddrDetectTransmits should default to 1 not 0. you can turn off DAD in your environment if you know you don't need it. /ot ------_=_NextPart_001_01C2F309.B3B8948E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DAD in node requirements draft

There may be some terminology/semantics that need to = be clarified regarding my usage of the term "link". What I = meant to convey was that for 3GPP (UMTS), a primary PDP context (and = its associated secondary PDP contexts) are treated as a single IPv6 = "link". But the GGSN views each primary PDP context as a = single "subnet". Therefore, DAD is not required. Similar for = 3GPP2 (cdma2000), except PPP is used, etc. 

Pete

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]
Sent: Tuesday, March 25, 2003 1:29 PM
To: Barany, Peter [RICH1:2H16:EXCH]
Cc: Mika Liljeberg; itojun@iijlab.net; = kuntal@iqmail.net;
ipng@sunroof.eng.sun.com
Subject: Re: DAD in node requirements draft


[...]

> During 3GPP (UMTS) work on PDP context = activation, it was agreed to make the
> /64 prefix unique per primary (and associated = secondary) PDP contexts so
> that DAD would not have to be performed = (particularly since privacy
> addresses are specified for use in 3GPP). See = RFC 3314 and, I believe, 3G TS
> 23.060 (and/or maybe another document in the = 3GPP 24 series).
>
> 3GPP2 (cdma2000) uses PPP and not a PDP = context. In IS-835-B it is stated
> that the /64 prefix(es) must be unique to that = PPP link ... again avoiding
> DAD when privacy addresses are used.

requiring that a /64 is unique on a link does not = avoid DAD.
doesn't the 3GPP specs restrict one end of the link = to not use any
addresses from the prefix, if so DAD is not = needed.

> Since the IETF IPv6 WG is in the process of = updating the IPv6 PPP RFC 2472
> (more specifically IPV6CP), my question is: = What changes are being planned
> to that RFC? Do any of these changes pertain to = the granularity/uniqueness
> of the /64 prefix? Thanks.

the only thing I can see requiring an update is that = the value of
DupAddrDetectTransmits should default to 1 not = 0.

you can turn off DAD in your environment if you know = you don't need
it.

/ot

------_=_NextPart_001_01C2F309.B3B8948E-- -------------------------------------------------------------------- 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 Mar 25 12:12:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PKCVVV022063; Tue, 25 Mar 2003 12:12:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PKCVSW022062; Tue, 25 Mar 2003 12:12:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PKCRVV022055 for ; Tue, 25 Mar 2003 12:12:27 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PKCZcU006639 for ; Tue, 25 Mar 2003 12:12:35 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02650 for ; Tue, 25 Mar 2003 12:12:30 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:12:29 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP; Tue, 25 Mar 2003 20:12:29 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP; Tue, 25 Mar 2003 20:12:29 Z Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by relay2.sun.com with ESMTP; Tue, 25 Mar 2003 20:12:29 Z Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6/8.11.6/2003.03.17) with ESMTP id h2PKCOX01527; Tue, 25 Mar 2003 21:12:24 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h2PKCOof078802; Tue, 25 Mar 2003 21:12:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200303252012.h2PKCOof078802@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Samita Chakrabarti , Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-reply-to: Your message of Tue, 25 Mar 2003 13:17:33 +0100. Date: Tue, 25 Mar 2003 21:12:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => what I propose is not pure per-process control, it is to put the > control in the context of processes. It gives immediatly a per-process > control but with a way to manage the context from applications, it gives > a per-socket control too. I didn't understand how the per-process context also gives you per-socket control. => this is like playing with UIDs, which are in the context of the application and can be set by set[e]uid() & co, to permit or deny access to privileged ports. My idea is to tune the context before performing some operations and to reset it after to its previous setup. Are you considering having setsockopts in addition to per-process context controls? => we can get both or even implement the per-process context via setsockopts. Or are you arguing that the setsockopt type of control is not necessary? => they are not necessary when a more general/flexible type of control is available and I argue this is the case for the process context stuff. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- 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 Mar 25 12:24:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PKOqVV022450; Tue, 25 Mar 2003 12:24:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PKOqMO022449; Tue, 25 Mar 2003 12:24:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PKOmVV022442 for ; Tue, 25 Mar 2003 12:24:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PKOucU011104 for ; Tue, 25 Mar 2003 12:24:56 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16909 for ; Tue, 25 Mar 2003 13:24:50 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:23:50 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:23:50 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:23:50 Z Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 20:23:49 Z Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2PKNXc19322; Tue, 25 Mar 2003 14:23:34 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 14:23:34 -0600 Message-Id: <1B54FA3A2709D51195C800508BF9386A080B37E6@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Ole Troan'" Cc: Mika Liljeberg , itojun@iijlab.net, kuntal@iqmail.net, ipng@sunroof.eng.sun.com Subject: RE: DAD in node requirements draft Date: Tue, 25 Mar 2003 14:23:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F30C.65FFA9AA" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F30C.65FFA9AA Content-Type: text/plain; charset="iso-8859-1" Also, I do not believe the change you suggest below for IPv6 over PPPbis would be needed for 3GPP2 (cdma2000), which uses PPP for MS to PDSN connectivity. Regards, Pete -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: Tuesday, March 25, 2003 1:29 PM To: Barany, Peter [RICH1:2H16:EXCH] Cc: Mika Liljeberg; itojun@iijlab.net; kuntal@iqmail.net; ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft [...] > During 3GPP (UMTS) work on PDP context activation, it was agreed to make the > /64 prefix unique per primary (and associated secondary) PDP contexts so > that DAD would not have to be performed (particularly since privacy > addresses are specified for use in 3GPP). See RFC 3314 and, I believe, 3G TS > 23.060 (and/or maybe another document in the 3GPP 24 series). > > 3GPP2 (cdma2000) uses PPP and not a PDP context. In IS-835-B it is stated > that the /64 prefix(es) must be unique to that PPP link ... again avoiding > DAD when privacy addresses are used. requiring that a /64 is unique on a link does not avoid DAD. doesn't the 3GPP specs restrict one end of the link to not use any addresses from the prefix, if so DAD is not needed. > Since the IETF IPv6 WG is in the process of updating the IPv6 PPP RFC 2472 > (more specifically IPV6CP), my question is: What changes are being planned > to that RFC? Do any of these changes pertain to the granularity/uniqueness > of the /64 prefix? Thanks. the only thing I can see requiring an update is that the value of DupAddrDetectTransmits should default to 1 not 0. you can turn off DAD in your environment if you know you don't need it. /ot ------_=_NextPart_001_01C2F30C.65FFA9AA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DAD in node requirements draft

Also, I do not believe the change you suggest below = for IPv6 over PPPbis would be needed for 3GPP2 (cdma2000), which uses = PPP for MS to PDSN connectivity.

Regards,

Pete

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]
Sent: Tuesday, March 25, 2003 1:29 PM
To: Barany, Peter [RICH1:2H16:EXCH]
Cc: Mika Liljeberg; itojun@iijlab.net; = kuntal@iqmail.net;
ipng@sunroof.eng.sun.com
Subject: Re: DAD in node requirements draft


[...]

> During 3GPP (UMTS) work on PDP context = activation, it was agreed to make the
> /64 prefix unique per primary (and associated = secondary) PDP contexts so
> that DAD would not have to be performed = (particularly since privacy
> addresses are specified for use in 3GPP). See = RFC 3314 and, I believe, 3G TS
> 23.060 (and/or maybe another document in the = 3GPP 24 series).
>
> 3GPP2 (cdma2000) uses PPP and not a PDP = context. In IS-835-B it is stated
> that the /64 prefix(es) must be unique to that = PPP link ... again avoiding
> DAD when privacy addresses are used.

requiring that a /64 is unique on a link does not = avoid DAD.
doesn't the 3GPP specs restrict one end of the link = to not use any
addresses from the prefix, if so DAD is not = needed.

> Since the IETF IPv6 WG is in the process of = updating the IPv6 PPP RFC 2472
> (more specifically IPV6CP), my question is: = What changes are being planned
> to that RFC? Do any of these changes pertain to = the granularity/uniqueness
> of the /64 prefix? Thanks.

the only thing I can see requiring an update is that = the value of
DupAddrDetectTransmits should default to 1 not = 0.

you can turn off DAD in your environment if you know = you don't need
it.

/ot

------_=_NextPart_001_01C2F30C.65FFA9AA-- -------------------------------------------------------------------- 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 Mar 25 13:19:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLJKVV022942; Tue, 25 Mar 2003 13:19:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PLJKVL022941; Tue, 25 Mar 2003 13:19:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLJGVV022933 for ; Tue, 25 Mar 2003 13:19:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PLJOcU004379 for ; Tue, 25 Mar 2003 13:19:24 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18778 for ; Tue, 25 Mar 2003 14:19:18 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:19:18 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:19:18 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:19:17 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:19:17 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 92E7D6A904; Tue, 25 Mar 2003 23:19:15 +0200 (EET) Message-Id: <3E80C7A8.1010309@kolumbus.fi> Date: Tue, 25 Mar 2003 23:18:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: Kurt Erik Lindqvist , ipng@sunroof.eng.sun.com Subject: Re: Mobility in Nodes Requirements References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDCD@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDCD@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Sorry for not getting back to this issue sooner, but I just got home after some touring at Tahoe and lengthy flights home.) > This is my exact point about this spec. > > It seems if this will continue without a focus as Kurtis says below and > I have stated previously we will need a serious applicability statement. > > Because it is BCP I am backing off a little as most of the market don't > care about our BCPs. But there needs to be applicability statement. Jim, Charter says Informational and I believe that is could be acceptable to you as well? If by "without a focus" you mean that we are not describing the requirements for IPv6-enabled servers flying in helichopters, then I agree. That is, we do not describe what IPv6 features should be used in specific applications. And yes, there should be an applicability statement to this effect. Perhaps you'd be willing to submit some text? However, I still feel strongly that we MUST describe what "components" IPv6 has and what their mandatory/optional status is. Not the need in a specific application, but whether something is *always* needed. And a directory of optional components. (In some specific subset of cases we can also give a rule when the optional component becomes mandatory.) I believe this is very useful for ensuring the interoperability and success of IPv6, and I'm a bit surprised that you seem to disagree. I've heard a number of counter arguments to this kind of specifications and I would like to take this opportunity to discuss them: * "Its obvious". Right. So why we are debating the keywords for DHCP and MIPv6...? * "Its in the other RFCs already". Probably so, at least in some cases. If you dig up the information by reading all RFCs, that is. And I know for a fact that some specifications explicitly left the decision out; at least MIPv6 does this in expectation of IPv6 saying something about it its specifications. * "We can't agree anyway what the mandatory components are". So, we shift our problem to the customers and end-users? No, let the buck stop here. Not in IESG, vendors, or customers. * "All this depends on the applications." Some things depend on the applications. But not all. And even if some things are needed on a per application basis, wouldn't it be useful to document that so that no one mistakes something for mandatory? * "Market place decides anyway." Yeah. But in my experience the rules in IETF specifications still have a lot of weight. * "The set of requirements for any specific application is going to be much different or more extensive than this". I agree. But no one claimed this was all you had to do to protect the flying servers. * "Maybe you can list the mandatory components, but I don't see a need to look at the optional ones." Well, how do I know that if RFC nnnn isn't listed, its (a) optional or (b) forgotten? I say we should be explicit and list the optional components too. * "Early IPv4 RFCs were so bad that we needed a lot of explanations, but it doesn't apply to IPv6 anymore". I agree, but if you look at the node requirements document, it doesn't follow the IPv4 host requirements style at all. We only list specific RFCs. There's a small number of cases where large RFCs contain a number of independent pieces (such as MIPv6) that we have also listed. But I agree, we shouldn't be explaining and patching existing RFCs. Fortunately, we are not doing that. Jari -------------------------------------------------------------------- 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 Mar 25 13:22:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLMRVV023009; Tue, 25 Mar 2003 13:22:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PLMRUQ023008; Tue, 25 Mar 2003 13:22:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLMMVV022986 for ; Tue, 25 Mar 2003 13:22:22 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PLMUHP008163 for ; Tue, 25 Mar 2003 13:22:30 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17975 for ; Tue, 25 Mar 2003 13:22:25 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:22:24 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:22:24 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:22:24 Z Received: from dhcp1.se.kurtis.pp.se (dhcp1.se.kurtis.pp.se [195.43.225.70]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:22:22 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h2PLNlWv000467; Tue, 25 Mar 2003 22:23:47 +0100 (CET) Date: Tue, 25 Mar 2003 22:23:46 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: EricLKlein , To: Quality Quorum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <1049A876-5F08-11D7-8DEC-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The same people are also trying to understand why a number of >> applications doesn't work in their network and how come that trojan >> send their password file to a unknown destination. Private addresses >> comes at a cost that is becoming more and more apparent. No need to >> pay >> that price in IPv6 as well as in IPv4. > > You can uniquely map each and every local address to a combination of a > single /64 + 64-bit unique id. So, organizations who care can have > static > mapping. Or real addresses? > >> >> If you absolutely want NAT take a random address block and NAT it for >> you. You will get the same problems / benefits. > > It would be nice to know that this block is not used for something > else. > Uhm, site-local blocks will most definite be used for something else... - kurtis - -------------------------------------------------------------------- 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 Mar 25 13:36:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLa8VV023485; Tue, 25 Mar 2003 13:36:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PLa8Fo023484; Tue, 25 Mar 2003 13:36:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLa4VV023477 for ; Tue, 25 Mar 2003 13:36:04 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PLaCHP013609 for ; Tue, 25 Mar 2003 13:36:12 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28616 for ; Tue, 25 Mar 2003 13:36:07 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:36:06 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:36:06 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:36:06 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:36:05 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2PLXAC03537; Tue, 25 Mar 2003 22:33:10 +0100 Message-Id: <3E80CB16.6010900@it.su.se> Date: Tue, 25 Mar 2003 22:33:10 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ole Troan CC: Mike Saywell , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <3E802BDB.1010504@it.su.se> <003401c2f2bd$c9d18f10$210d640a@unfix.org> <20030325115319.GI18295@ecs.soton.ac.uk> <3E806A4F.40800@it.su.se> <7t51y0vo5hx.fsf@mrwint.cisco.com> In-Reply-To: <7t51y0vo5hx.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole Troan wrote: >IPv6 has multiple addresses anyway. or do you propose to remove >link-locals too? > >/ot > > Link-local are used in very special cases (bootstrap for instance) which have to have lots of special case handling today anyway. Not a problem. -------------------------------------------------------------------- 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 Mar 25 13:48:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLmNVV023834; Tue, 25 Mar 2003 13:48:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PLmNX5023833; Tue, 25 Mar 2003 13:48:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PLmJVV023823 for ; Tue, 25 Mar 2003 13:48:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PLmRcU014821 for ; Tue, 25 Mar 2003 13:48:27 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14866 for ; Tue, 25 Mar 2003 14:48:22 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:48:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:45:29 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:48:21 Z Received: from TheWorld.com ([199.172.62.106] [199.172.62.106]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 21:48:20 Z Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.12.8/8.12.8) with ESMTP id h2PLmCaP014063; Tue, 25 Mar 2003 16:48:12 -0500 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA6628896; Tue, 25 Mar 2003 16:48:12 -0500 (EST) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Tue, 25 Mar 2003 16:48:12 -0500 From: Quality Quorum To: Kurt Erik Lindqvist cc: EricLKlein , Subject: Re: A use for site local addresses? In-Reply-To: <1049A876-5F08-11D7-8DEC-000393AB1404@kurtis.pp.se> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 25 Mar 2003, Kurt Erik Lindqvist wrote: > >> The same people are also trying to understand why a number of > >> applications doesn't work in their network and how come that trojan > >> send their password file to a unknown destination. Private addresses > >> comes at a cost that is becoming more and more apparent. No need to > >> pay > >> that price in IPv6 as well as in IPv4. > > > > You can uniquely map each and every local address to a combination of a > > single /64 + 64-bit unique id. So, organizations who care can have > > static > > mapping. > > Or real addresses? Yes, but I would not be surprised to see a lot of organizations selecting private space + NAT. I do not think that there is a compelling case to do otherwise. > >> If you absolutely want NAT take a random address block and NAT it for > >> you. You will get the same problems / benefits. > > > > It would be nice to know that this block is not used for something > > else. > > > Uhm, site-local blocks will most definite be used for something else... > > - kurtis - > Thanks, Aleksey -------------------------------------------------------------------- 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 Mar 25 14:40:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PMeAVV024733; Tue, 25 Mar 2003 14:40:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PMeATn024732; Tue, 25 Mar 2003 14:40:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PMe5VV024725 for ; Tue, 25 Mar 2003 14:40:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PMeCHP010148 for ; Tue, 25 Mar 2003 14:40:13 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25388 for ; Tue, 25 Mar 2003 15:40:07 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:40:06 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:40:06 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:40:06 Z Received: from ietf.org ([132.151.1.176] [132.151.1.176]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:40:06 Z Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07411; Tue, 25 Mar 2003 17:37:35 -0500 (EST) Message-Id: <200303252237.RAA07411@ietf.org> To: IETF-Announce:; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: IPv6 Global Unicast Address Format to Informational Reply-to: iesg@ietf.org Date: Tue, 25 Mar 2003 17:37:35 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request to consider 'IPv6 Global Unicast Address Format' as an Informational RFC. This document will replace RFC2374 and reclassify RFC 2374 (and the TLA/NLA structure described there) as historic. 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 2003-4-8. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-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 Tue Mar 25 14:46:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PMkIVV024886; Tue, 25 Mar 2003 14:46:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PMkIO9024883; Tue, 25 Mar 2003 14:46:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PMkEVV024872 for ; Tue, 25 Mar 2003 14:46:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PMkMcU007708 for ; Tue, 25 Mar 2003 14:46:22 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29830 for ; Tue, 25 Mar 2003 15:46:16 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:45:47 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:45:47 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:45:47 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:45:46 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h2PMjjdk072300 for ; Tue, 25 Mar 2003 23:45:45 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2PMjjCX224006 for ; Tue, 25 Mar 2003 23:45:45 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA21424 from ; Tue, 25 Mar 2003 23:45:43 +0100 Message-Id: <3E80DBD6.9083927E@hursley.ibm.com> Date: Tue, 25 Mar 2003 23:44:38 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quality Quorum wrote: > > On Tue, 25 Mar 2003, Kurt Erik Lindqvist wrote: > > > >> The same people are also trying to understand why a number of > > >> applications doesn't work in their network and how come that trojan > > >> send their password file to a unknown destination. Private addresses > > >> comes at a cost that is becoming more and more apparent. No need to > > >> pay > > >> that price in IPv6 as well as in IPv4. > > > > > > You can uniquely map each and every local address to a combination of a > > > single /64 + 64-bit unique id. So, organizations who care can have > > > static > > > mapping. > > > > Or real addresses? > > Yes, but I would not be surprised to see a lot of organizations selecting > private space + NAT. I do not think that there is a compelling case > to do otherwise. We have a couple of RFCs about that, but since it's tired old argument, let's just not go there yet again. Brian -------------------------------------------------------------------- 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 Mar 25 14:50:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PMofVV025079; Tue, 25 Mar 2003 14:50:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PMofcE025078; Tue, 25 Mar 2003 14:50:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PMobVV025071 for ; Tue, 25 Mar 2003 14:50:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PMojHP014336 for ; Tue, 25 Mar 2003 14:50:45 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13725 for ; Tue, 25 Mar 2003 15:50:38 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:50:34 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:50:33 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:50:33 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 22:50:33 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 317788F6F; Tue, 25 Mar 2003 23:50:29 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D49D88F69; Tue, 25 Mar 2003 23:50:23 +0100 (CET) From: "Jeroen Massar" To: "'Tim Hartrick'" Cc: Subject: RE: A use for site local addresses? Date: Tue, 25 Mar 2003 23:51:24 +0100 Organization: Unfix Message-Id: <002801c2f321$111da120$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <200303251920.LAA19153@feller.mentat.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2PMocVV025072 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Hartrick [mailto:tim@mentat.com] wrote: > > Enduser ISP's will always charge for extra IP space as it's > > currently not customary to give an enduser more than 1 IP. > > Also IPv4 is a becoming a 'scarce' resource. > > > > And what precisely will change this custom for IPv6? Quoting RFCs > is silly in the face of MBAs motivated by profit. It is folly. Then I would suggest that you either educate them that IPv4 != Ipv6. This is one thing one will have to do anyways. Just like the fact that IPX != TCP/IP. Also if one doesn't want to follow RFC's then don't expect to be able to communicate properly with the rest of the world. But ofcourse that is my point of view and I don't like taking into account money in technical matters. > > > Absent some regulation, there is no reason to believe that > > > they will stop charging for IPv6 address space no matter > > > how freely the bits are made available to them. > > > It would be great if ISPs would charge for bandwidth > > > only but that simply isn't the way the world currently works > > > and there is absolutely nothing about IPv6 that will change that. > > > More bits in the address don't mean diddly if the only way to > > > get the bits is through an oligarchy of ISPs. > > > > If the ISP doesn't provide /48's to an endsite, other ISP's > > will have the advantage that they do. Also if the ISP doesn't > > they are going against RFC's. > > > > RFCs fall regularly in the face of the profit motive. Like above, if you opt not to follow RFC's, STD's etc don't expect to be able to communicate. > > You might also realize that the current TLA policy for RIR's > > demands that you have 200 prospect clients. That is 200x /48. > > Aka 200 endusers on DSL will suffice for them. > > > > Currently even most tunnelbroker system endusers get > > a /48 and in some cases even more. And they are not even > > paying for bandwidth nor for ipspace. Go figure ;) > > > > I have little faith that the current state of affairs will > resemble the eventual state of affairs. No one currently > expects to make money from IPv6. Once they do, address > space will become a profit center. MBAs don't care about RFCs. I think you meant: s/no one/apparently no one in the US/ Welcome to the global Internet where Asia is leading the developments. > Don't get me wrong I don't mind ISPs making a profit. If they don't I > won't have service but that doesn't mean that every small and medium > size business that can't pass itself off as an ISP should have their > internal topology held hostage by the local oligopoly of ISP. I agree indeed, this is what is the _current_ practice in the IPv4 world is. But if we, the people deploying IPv6, clue in the ISP's enough that they should not and I haven't heared of any ISP who is asking money because 'the customer wants a /48 and we don't have much address space' If you have other versions of this story please show them. > ISPs. Small and medium sized businesses simply won't accept > that cost risk and will promptly move to using NAT to protect > themselves from renumbering and/or cost uncertainty. > They can't really be expected to do anything else given IPv4's > history of real and manufactured address scarcity. If they are out to use NATs any way they can, I see absolutely no reason for them to use IPv6 at all. Either clue them in that they should follow the RFC's and spread /48's or let them keep their NATs which will break Again, this talk is about 'uncertainty', quite possibly because of the 'fear' that they are going to change upstreams etc. IMHO that can be fixed by Multihoming solutions, not by using NAT's. And therefor I still see no need for link-locals. To sum up, the only reasons I have seen so far and please add to list if I miss a couple, which is quite probable and very much related to NATs, which are being discussed for deprecation also... - Impact of site-local addressing -- Margaret Wasserman http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx t The appendix has a part about limitting usage to single sites. But that has their own implications when the site does get global connectivity or merge with another company and we are at NAT again. And on this list have been named: - Merging networks, then using NATs because the address space is not unique. -> Use public IP space from your upstream. If you are not big enough for your own TLA you apparently haven't got a big or own network so renumbering should not be much of a pain. Another option: Multihoming. - My printer can be reached from the internet. -> Use a firewall; NAT won't 'protect' you. Any others? BTW: let me note that I know of a certain hospital with a /16 IPv4 and all their heartmonitoring and other surveilance apparatus are using IP's out of that /16. With one big, good configured, firewall at the gate and ofcourse nice VLAN's which don't even allow packets from those VLAN's to come even close to the internet. Now I quickly hear a "why do they have a public /16", because it's globally unique and they can easily merge with another hospital or organization and don't have to 'fear/uncertainty/doubt' that their address spaces will ever collide. Oh and for the question of how much v6 they would need: a single /48 would suffice as it would allow 65535 networks or quite possibly VLAN's. And yes they could receive that from their current upstream which also delivers the /16 to their doorstep. It's kinda cheating because it's internet from an NREN but even then it's a reallife version of what is done with IPv4 and how it can be done with IPv6. Problem in IPv4 is simply that you can't get the space, but it will simply have to change otherwise expanding the address space to 128 bits is futile and we can stay at the non-e2e NATted IPv4. With all the problems which come along with that... Greets, Jeroen -------------------------------------------------------------------- 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 Mar 25 15:31:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PNV3VV025710; Tue, 25 Mar 2003 15:31:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2PNV3fb025709; Tue, 25 Mar 2003 15:31:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2PNV0VV025702 for ; Tue, 25 Mar 2003 15:31:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2PNV7cU024602 for ; Tue, 25 Mar 2003 15:31:07 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00594 for ; Tue, 25 Mar 2003 16:30:45 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 23:30:10 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 23:27:18 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 23:30:10 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 23:30:10 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA15258 for ; Tue, 25 Mar 2003 23:30:09 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA23359 for ; Tue, 25 Mar 2003 23:30:08 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2PNU8S07813 for ipng@sunroof.eng.sun.com; Tue, 25 Mar 2003 23:30:08 GMT Date: Tue, 25 Mar 2003 23:30:08 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030325233008.GR18295@ecs.soton.ac.uk> References: <200303251920.LAA19153@feller.mentat.com> <002801c2f321$111da120$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002801c2f321$111da120$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 25, 2003 at 11:51:24PM +0100, Jeroen Massar wrote: > To sum up, the only reasons I have seen so far and please add to > list if I miss a couple, which is quite probable and very much > related to NATs, which are being discussed for deprecation also... > > - Impact of site-local addressing -- Margaret Wasserman > > http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.tx > t > > The appendix has a part about limitting usage to single sites. > But that has their own implications when the site does get global > connectivity or merge with another company and we are at NAT again. > > And on this list have been named: > > - Merging networks, then using NATs because the address space > is not unique. > -> Use public IP space from your upstream. > If you are not big enough for your own TLA you apparently > haven't got a big or own network so renumbering > should not be much of a pain. Another option: Multihoming. > > - My printer can be reached from the internet. > -> Use a firewall; NAT won't 'protect' you. > > Any others? > Well, there's my original reason... - My network is operator independant but I'm not a multi-national company or an ISP (thus not in a position to obtain address space directly from a registry). Also... - Ad-hoc networks become restricted to link local addresses and thus a single flat subnet. The latter is perhaps covered by the appendix in the draft, but I do not beleive the former has been addressed. Cheers, Mike -------------------------------------------------------------------- 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 Mar 25 16:12:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q0CQVV026154; Tue, 25 Mar 2003 16:12:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2Q0CQLb026153; Tue, 25 Mar 2003 16:12:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q0CNVV026146 for ; Tue, 25 Mar 2003 16:12:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2Q0CUcU009665 for ; Tue, 25 Mar 2003 16:12:31 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20337 for ; Tue, 25 Mar 2003 17:12:25 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 00:12:25 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 00:09:32 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 00:12:24 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 00:12:24 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 4AE38137F09; Tue, 25 Mar 2003 16:12:22 -0800 (PST) Date: Tue, 25 Mar 2003 16:12:22 -0800 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Tim Hartrick'" , To: "Jeroen Massar" From: David Conrad In-Reply-To: <007601c2f2fc$ff5e84a0$210d640a@unfix.org> Message-Id: <9DBA686A-5F1F-11D7-BDFE-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen, On Tuesday, March 25, 2003, at 10:33 AM, Jeroen Massar wrote: > Enduser ISP's will always charge for extra IP space as it's > currently not customary to give an enduser more than 1 IP. Varies per service provider. My home ISP, for example, provides 2 static addresses for the package I purchased. I frequently heard of ISPs allocating /24s to customers, although that was a while back. > Also IPv4 is a becoming a 'scarce' resource. Of course, IANA just 'found' another 350 million unused addresses... > You might also realize that the current TLA policy for RIR's > demands that you have 200 prospect clients. That is 200x /48. > Aka 200 endusers on DSL will suffice for them. For those interested in address allocation policy, I might suggest participating in the RIR public policy mailing lists and meetings (ppml@arin.net and the upcoming Memphis meeting for those in the ARIN region). Rgds, -drc -------------------------------------------------------------------- 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 Mar 25 19:14:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q3ExVV027038; Tue, 25 Mar 2003 19:14:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2Q3Ew1K027037; Tue, 25 Mar 2003 19:14:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q3EsVV027030 for ; Tue, 25 Mar 2003 19:14:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2Q3F2cU009010 for ; Tue, 25 Mar 2003 19:15:02 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27656 for ; Tue, 25 Mar 2003 20:14:56 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:14:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:12:03 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:14:55 Z Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:14:55 Z Received: from sdn-ap-023txhousp0203.dialsprint.net ([65.177.40.203] helo=cs.utk.edu) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18y1NC-0002LI-00; Tue, 25 Mar 2003 19:14:42 -0800 Date: Tue, 25 Mar 2003 22:14:38 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , "'Kurt Erik Lindqvist'" , "'EricLKlein'" , To: From: Keith Moore In-Reply-To: <03ec01c2f2ff$432bee50$ee1a4104@eagleswings> Message-Id: <13E98A20-5F39-11D7-8225-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, March 25, 2003, at 01:49 PM, Tony Hain wrote: >> Site-locals was voted down in the WG meeting in SF. > > The IETF doesn't vote ... and there is no way a decision gets made in a > meeting. It doesn't matter that a few vocal people want to remove a > capability because they don't understand it, the rules of the IETF are > that decisions are based on mail list discussions. Tony, It wasn't a few vocal people. It was an overwhelming majority. There were far more people in favor of deprecating site locals at that meeting, than the set of people in favor of site locals even if you include those on the list those who weren't present at that meeting. It was a clear consensus of the working group. And yes, you can make a decision in a face-to-face meeting if there is such overwhelming support for the decision at the meeting that there simply aren't enough people on the mailing list to affect the consensus. > Site-locals are useful exactly for the case that started this thread, Site-locals are useful, but the cost is too high. The additional complexity that site locals add to nearly every part of the Internet - in apps, DNS, routing, and elsewhere - simply isn't worth the benefit. There are less expensive ways to provide the same functionality. Keith -------------------------------------------------------------------- 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 Mar 25 19:18:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q3IIVV027097; Tue, 25 Mar 2003 19:18:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2Q3IIAT027096; Tue, 25 Mar 2003 19:18:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q3IDVV027086 for ; Tue, 25 Mar 2003 19:18:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2Q3ILHP008558 for ; Tue, 25 Mar 2003 19:18:21 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA29286 for ; Tue, 25 Mar 2003 20:18:16 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:18:15 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:18:15 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:18:15 Z Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 03:18:15 Z Received: from sdn-ap-023txhousp0203.dialsprint.net ([65.177.40.203] helo=cs.utk.edu) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18y1Qa-000079-00; Tue, 25 Mar 2003 19:18:13 -0800 Date: Tue, 25 Mar 2003 22:18:10 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , ipng@sunroof.eng.sun.com To: Brian E Carpenter From: Keith Moore In-Reply-To: <3E808A2F.7837A9C3@hursley.ibm.com> Message-Id: <9224C664-5F39-11D7-8225-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Multiple addresses per host are a real-world feature of IPv4 and have > always been a design goal of IPv6. > > We've already defined the default address selection algorithm (RFC > 3484). > Applications are welcome to use a different algorithm, but they > don't need to, which is why the default was defined. it's one thing to allow multiple addresses per host in the architecture, quite another to expect hosts and apps to be able to tolerate different addresses with different scopes and force them to choose between these addresses in order to interoperate. the default address selection algorithm will only work in a fairly narrow set of cases. it's simply not the case that applications "don't need to" use a different algorithm. -------------------------------------------------------------------- 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 Mar 25 21:38:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q5c6VV027950; Tue, 25 Mar 2003 21:38:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2Q5c5Dx027949; Tue, 25 Mar 2003 21:38:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q5c2VV027942 for ; Tue, 25 Mar 2003 21:38:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2Q5cAcU008194 for ; Tue, 25 Mar 2003 21:38:10 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03320 for ; Tue, 25 Mar 2003 21:38:04 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 05:37:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 05:35:01 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 05:37:54 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 05:37:54 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id C0DC9508F08; Tue, 25 Mar 2003 21:37:53 -0800 (PST) To: Keith Moore Cc: alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from Keith Moore dated Tue, 25 Mar 2003 22:14:38 EST <13E98A20-5F39-11D7-8225-000393DB5366@cs.utk.edu> Date: Tue, 25 Mar 2003 21:37:53 -0800 From: Naiming Shen Message-Id: <20030326053753.C0DC9508F08@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As long as we are clear that, the "site-local" does not get special treatment in terms of routing and dns, we should care less about if "site-local" is deprecated or still lived. It's perfectly fine and actually somewhat useful if "site-local" plays the same role as in IPv4 addresses defined in rfc1918. ] ] On Tuesday, March 25, 2003, at 01:49 PM, Tony Hain wrote: ] ] >> Site-locals was voted down in the WG meeting in SF. ] > ] > The IETF doesn't vote ... and there is no way a decision gets made in a ] > meeting. It doesn't matter that a few vocal people want to remove a ] > capability because they don't understand it, the rules of the IETF are ] > that decisions are based on mail list discussions. ] ] Tony, ] ] It wasn't a few vocal people. It was an overwhelming majority. There ] were far more people in favor of deprecating site locals at that ] meeting, than the set of people in favor of site locals even if you ] include those on the list those who weren't present at that meeting. ] It was a clear consensus of the working group. And yes, you can make a ] decision in a face-to-face meeting if there is such overwhelming ] support for the decision at the meeting that there simply aren't enough ] people on the mailing list to affect the consensus. ] ] > Site-locals are useful exactly for the case that started this thread, ] ] Site-locals are useful, but the cost is too high. The additional ] complexity that site locals add to nearly every part of the Internet - ] in apps, DNS, routing, and elsewhere - simply isn't worth the benefit. ] There are less expensive ways to provide the same functionality. ] ] Keith ] ] -------------------------------------------------------------------- ] 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 ] -------------------------------------------------------------------- - Naiming -------------------------------------------------------------------- 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 Mar 25 23:29:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q7T9VV028588; Tue, 25 Mar 2003 23:29:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2Q7T9oM028587; Tue, 25 Mar 2003 23:29:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2Q7T5VV028580 for ; Tue, 25 Mar 2003 23:29:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2Q7T7HP027220 for ; Tue, 25 Mar 2003 23:29:07 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10197 for ; Wed, 26 Mar 2003 00:29:00 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 07:28:40 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 07:28:39 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 07:28:39 Z Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 07:28:38 Z Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HCC00J01I3P0C@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:28:37 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HCC00DZ7I3OPL@mailout3.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:28:36 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HCC006HHI3O4S@mmp1.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:28:36 +0900 (KST) Date: Wed, 26 Mar 2003 16:27:25 +0900 From: Soohong Daniel Park Subject: RE: DAD in node requirements draft In-reply-to: <1048617786.12768.18.camel@devil> To: "'Mika Liljeberg'" , itojun@iijlab.net Cc: kuntal@iqmail.net, ipng@sunroof.eng.sun.com Message-Id: <009a01c2f369$262e9d60$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The efficiency depends on operator policy. Sometimes we have to perform the DAD with all addresses. Daniel -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Mika Liljeberg Sent: Wednesday, March 26, 2003 3:43 AM To: itojun@iijlab.net Cc: kuntal@iqmail.net; ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft On Tue, 2003-03-25 at 04:27, itojun@iijlab.net wrote: > it makes more sense when rules are simpler. if you always perform DAD > you can always ensure there's no duplicate. even if machine A is > autoconfigured with prefix P::/64 and DAD-safe link-local address > fe80::ID, the other end could configure P:ID intentionally. It would be more efficient to always do DAD with the link-local prefix rather than full address, and just ensure that each IID is owned by a single machine. I.e., if you configure P:ID, do dad with FE80:ID (unless already done) and defend all X:ID. MikaL -------------------------------------------------------------------- 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 Mar 26 02:54:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QAs6VV029385; Wed, 26 Mar 2003 02:54:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QAs6WP029384; Wed, 26 Mar 2003 02:54:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QAs3VV029377 for ; Wed, 26 Mar 2003 02:54:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QAsBHP005695 for ; Wed, 26 Mar 2003 02:54:11 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17328 for ; Wed, 26 Mar 2003 02:54:05 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 10:54:04 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 10:54:04 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 10:54:03 Z Received: from c001.snv.cp.net ([209.228.32.119] [209.228.32.119]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 10:54:03 Z Received: (cpmta 13468 invoked from network); 26 Mar 2003 02:54:01 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.119) with SMTP; 26 Mar 2003 02:54:01 -0800 X-Sent: 26 Mar 2003 10:54:01 GMT Message-Id: <005401c2f386$37d63e70$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <007601c2f2fc$ff5e84a0$210d640a@unfix.org> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 12:55:28 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If the ISP doesn't provide /48's to an endsite, other ISP's > will have the advantage that they do. Also if the ISP doesn't > they are going against RFC's. > > You might also realize that the current TLA policy for RIR's > demands that you have 200 prospect clients. That is 200x /48. > Aka 200 endusers on DSL will suffice for them. Yes, but what we are saying is 200 clients per DSL user, not per DSLAM. Each and every person with DSL access would be geting those 200 evenif it is for 1 PC. Some how I don't see it happening this way in the real world. RFC or otherwise. -------------------------------------------------------------------- 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 Mar 26 03:04:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QB4RVV029541; Wed, 26 Mar 2003 03:04:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QB4RnI029540; Wed, 26 Mar 2003 03:04:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QB4NVV029531 for ; Wed, 26 Mar 2003 03:04:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QB4WcU016133 for ; Wed, 26 Mar 2003 03:04:32 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21194 for ; Wed, 26 Mar 2003 04:04:27 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:03:59 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:03:59 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:03:58 Z Received: from c001.snv.cp.net ([209.228.32.114] [209.228.32.114]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:03:58 Z Received: (cpmta 23233 invoked from network); 26 Mar 2003 03:03:57 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.114) with SMTP; 26 Mar 2003 03:03:57 -0800 X-Sent: 26 Mar 2003 11:03:57 GMT Message-Id: <006401c2f387$9acd8550$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 13:05:23 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Done this way we will be defingin IPv7 real quick, as the unused > > addresses > > will add up very fast. > > There are a _lot_ of IPv6 routing prefixes, namely 281,474,976,710,656 > (assuming every allocation is a /48 as is the current plan (last I > heard)). Right now, there are about 120K routing prefixes in the > Internet. I think IPv7 is a ways off. > Not if we are assigning 200 addresses to each user (never to be reclaimed in many cases) They touted IPv6 as 1 address per person in the world for years to come. Look at the future. You will need (assumes modern western culture person other cultures may have different requirements as defined by B. Gates): 1 address per node on your computer (all must be registered as local addresses are going away according to the list) 1 address for your work computer + printer + other "smart" device 1 address per hand held (Palm, IPaq, etc) 1 address per cellular phone 1 address per regular phone (possibly 1 per physical extension in your house - but I think that can be avoided) 1 address per appliance on your network - Refrigerator, dishwasher, air conditioner, alarm system, car radio, etc (again all must be registered as above) and more address as they are used. This will make it a case of the person in 2000 who has 15 phone numbers for their family of 4 changing to the person in 2005 who had 200 IP addresses (or names that DNS to addresses) for their house plus 50 addresses for that same family of 4. Some sort of local addresses space is a must. -------------------------------------------------------------------- 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 Mar 26 03:06:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QB6bVV029606; Wed, 26 Mar 2003 03:06:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QB6bef029605; Wed, 26 Mar 2003 03:06:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QB6YVV029598 for ; Wed, 26 Mar 2003 03:06:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QB6hHP007977 for ; Wed, 26 Mar 2003 03:06:43 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15815 for ; Wed, 26 Mar 2003 04:06:37 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:06:35 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:03:41 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:06:34 Z Received: from c001.snv.cp.net ([209.228.32.114] [209.228.32.114]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:06:34 Z Received: (cpmta 24901 invoked from network); 26 Mar 2003 03:06:32 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.114) with SMTP; 26 Mar 2003 03:06:32 -0800 X-Sent: 26 Mar 2003 11:06:32 GMT Message-Id: <006f01c2f387$f70268e0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 13:07:58 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> IP's should be globably unique. Which will overcome many problems > >> like network mergers ('oh we need to NAT now'), e2e problems etc. > > The new address features of IPv6 should resolve this as easily as > > changing > > providers. > > What features are those? Autoconfiguration - IPV6 allows autoconfiguration of the devices by either the router, DHCP server or both. This should resolve most of the problems when merging networks, just change the part atthe front of the /64 (or /48) address and leave the hosts the same. SHould work the same as changing the ISP. -------------------------------------------------------------------- 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 Mar 26 03:13:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBDHVV029974; Wed, 26 Mar 2003 03:13:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QBDGRm029973; Wed, 26 Mar 2003 03:13:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBDDVV029966 for ; Wed, 26 Mar 2003 03:13:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QBDMcU017991 for ; Wed, 26 Mar 2003 03:13:22 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19897 for ; Wed, 26 Mar 2003 04:13:16 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:13:16 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:10:21 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:13:14 Z Received: from c001.snv.cp.net ([209.228.32.134] [209.228.32.134]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:13:14 Z Received: (cpmta 22835 invoked from network); 26 Mar 2003 03:13:05 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.134) with SMTP; 26 Mar 2003 03:13:05 -0800 X-Sent: 26 Mar 2003 11:13:05 GMT Message-Id: <015b01c2f388$e1ad7ba0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <3E802BDB.1010504@it.su.se> <003401c2f2bd$c9d18f10$210d640a@unfix.org> <20030325115319.GI18295@ecs.soton.ac.uk> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 13:14:31 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I can't really see the motivations to do NAT under v6 when it's so easy > to have multiple addresses on an interface anyway. Joining 2 networks > which use the same address site-local addresses would be nowhere near > as painfull as before since it's that much easier to re-number one of > them under v6. > I agree, under the autoconfigure feature you should be able to do this easily. Say that both networks were using the FE8::xxxx:xxxx network, then one of them could change this to FE9::xxxx:xxxx prior to the merge, and then just link them. Should be a piece of cake. An alternative would be simply to go from both being FE8::xxxx:xxxx to one being FE8:1::xxxx:xxxx and the other being FE8:2::xxxx:xxxx This way there would be the ability of splitting sites and such by the thousands, and only using NAT for the public Internet connections. -------------------------------------------------------------------- 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 Mar 26 03:19:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBJOVV000317; Wed, 26 Mar 2003 03:19:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QBJOoe000316; Wed, 26 Mar 2003 03:19:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBJKVV000298 for ; Wed, 26 Mar 2003 03:19:20 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QBJTHP010563 for ; Wed, 26 Mar 2003 03:19:29 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02590 for ; Wed, 26 Mar 2003 03:19:23 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:19:23 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:16:24 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:19:17 Z Received: from c001.snv.cp.net ([209.228.32.135] [209.228.32.135]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:19:17 Z Received: (cpmta 16280 invoked from network); 26 Mar 2003 03:19:15 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.135) with SMTP; 26 Mar 2003 03:19:15 -0800 X-Sent: 26 Mar 2003 11:19:15 GMT Message-Id: <016501c2f389$be32e1f0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <002801c2f321$111da120$210d640a@unfix.org> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 13:20:42 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't like taking into account money in technical matters. > Welcome to the eral world, not the lab or academic world. > > BTW: let me note that I know of a certain hospital with a /16 IPv4 > and all their heartmonitoring and other surveilance apparatus > are using IP's out of that /16. With one big, good configured, > firewall at the gate and ofcourse nice VLAN's which don't even > allow packets from those VLAN's to come even close to the internet. > Now I quickly hear a "why do they have a public /16", because it's > globally unique and they can easily merge with another hospital > or organization and don't have to 'fear/uncertainty/doubt' that > their address spaces will ever collide. Oh and for the question > of how much v6 they would need: a single /48 would suffice as > it would allow 65535 networks or quite possibly VLAN's. And yes > they could receive that from their current upstream which also > delivers the /16 to their doorstep. > Your explination seems to take into account the pre IPv6 autoconfigure options which are supposed to make this merger or provider change eaiser to handle. They used the IPv4 space as they did because there was nothing better, but what we are supposed to be doing is providing this bigger better plan. -------------------------------------------------------------------- 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 Mar 26 03:23:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBNDVV000501; Wed, 26 Mar 2003 03:23:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QBNDOE000500; Wed, 26 Mar 2003 03:23:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBN9VV000490 for ; Wed, 26 Mar 2003 03:23:09 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QBNIcU019896 for ; Wed, 26 Mar 2003 03:23:18 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04794 for ; Wed, 26 Mar 2003 03:23:13 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:22:48 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:22:38 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:22:38 Z Received: from c001.snv.cp.net ([209.228.32.134] [209.228.32.134]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:22:38 Z Received: (cpmta 24748 invoked from network); 26 Mar 2003 03:22:36 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.134) with SMTP; 26 Mar 2003 03:22:36 -0800 X-Sent: 26 Mar 2003 11:22:36 GMT Message-Id: <017101c2f38a$35f59ac0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: , "Keith Moore" Cc: "Keith Moore" , "'Kurt Erik Lindqvist'" , "'EricLKlein'" , References: <13E98A20-5F39-11D7-8225-000393DB5366@cs.utk.edu> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 13:24:01 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Site-locals are useful, but the cost is too high. The additional > complexity that site locals add to nearly every part of the Internet - > in apps, DNS, routing, and elsewhere - simply isn't worth the benefit. How high is the cost of setting a standard that says the following 4 prefixes are not broadcast over the Internet? It is one short rule in all of the systems. > There are less expensive ways to provide the same functionality. Could you name a few that take into account not having an ISP providing addresses. -------------------------------------------------------------------- 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 Mar 26 03:25:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBPCVV000627; Wed, 26 Mar 2003 03:25:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QBPCiF000626; Wed, 26 Mar 2003 03:25:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBP8VV000613 for ; Wed, 26 Mar 2003 03:25:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QBPGcU020315 for ; Wed, 26 Mar 2003 03:25:17 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27182 for ; Wed, 26 Mar 2003 04:25:11 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:25:10 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:25:10 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:25:10 Z Received: from c001.snv.cp.net ([209.228.32.139] [209.228.32.139]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:25:10 Z Received: (cpmta 17801 invoked from network); 26 Mar 2003 03:25:08 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 26 Mar 2003 03:25:08 -0800 X-Sent: 26 Mar 2003 11:25:08 GMT Message-Id: <017b01c2f38a$903cdf20$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <20030326053753.C0DC9508F08@prattle.redback.com> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 13:26:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As long as we are clear that, the "site-local" does not get special > treatment in terms of routing and dns, we should care less about if > "site-local" is deprecated or still lived. It's perfectly fine and > actually somewhat useful if "site-local" plays the same role as in > IPv4 addresses defined in rfc1918. > Or to ask it a different way, (and maybe this is the solution) will all of the 10.x.x.x (and the other IPv4 private addresses) suddenly become globally broadcast? This is a bigger problem. What will an IPv6 application or hardware do with a ::10.x.x.x address? -------------------------------------------------------------------- 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 Mar 26 03:44:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBiBVV001315; Wed, 26 Mar 2003 03:44:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QBiBAT001314; Wed, 26 Mar 2003 03:44:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QBi7VV001307 for ; Wed, 26 Mar 2003 03:44:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QBiFHP014633 for ; Wed, 26 Mar 2003 03:44:16 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29313 for ; Wed, 26 Mar 2003 04:44:10 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:44:10 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:44:09 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:44:09 Z Received: from starfruit.itojun.org ([210.130.48.137] [210.130.48.137]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 11:44:07 Z Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 12CAA791; Wed, 26 Mar 2003 20:42:33 +0900 (JST) To: Mika Liljeberg Cc: ipng@sunroof.eng.sun.com In-reply-to: mika.liljeberg's message of 25 Mar 2003 21:07:48 +0200. <1048619267.12768.34.camel@devil> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DAD in node requirements draft From: Jun-ichiro itojun Hagino Date: Wed, 26 Mar 2003 20:42:33 +0900 Message-Id: <20030326114233.12CAA791@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> note the mechanism is called DAD not DIID. this has >> been discussed to death numerous times, please refer to the archive. >I know. Means people still disagree about it. how can you prevent random other node to assign P::X (which you are using and verified fe80::X by DAD) on the interface? DIID does not work in practice. itojun -------------------------------------------------------------------- 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 Mar 26 05:10:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QDA0VV001723; Wed, 26 Mar 2003 05:10:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QDA0pI001722; Wed, 26 Mar 2003 05:10:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QD9vVV001715 for ; Wed, 26 Mar 2003 05:09:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QDA5HP029433 for ; Wed, 26 Mar 2003 05:10:05 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29377 for ; Wed, 26 Mar 2003 06:10:00 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:09:59 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:07:03 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:09:57 Z Received: from dhcp1.se.kurtis.pp.se ([192.71.80.74] [192.71.80.74]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:09:56 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h2QDBMWv000673; Wed, 26 Mar 2003 14:11:23 +0100 (CET) Date: Wed, 26 Mar 2003 14:11:22 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: EricLKlein , To: Quality Quorum From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <70D02E6C-5F8C-11D7-8DEC-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Yes, but I would not be surprised to see a lot of organizations > selecting > private space + NAT. I do not think that there is a compelling case > to do otherwise. You will break a number of applications. - kurtis - -------------------------------------------------------------------- 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 Mar 26 05:52:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QDq6VV002674; Wed, 26 Mar 2003 05:52:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QDq6Wj002673; Wed, 26 Mar 2003 05:52:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QDq3VV002666 for ; Wed, 26 Mar 2003 05:52:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QDqBcU017617 for ; Wed, 26 Mar 2003 05:52:12 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAB27351 for ; Wed, 26 Mar 2003 06:52:06 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:52:05 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:49:10 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:52:04 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:52:03 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2QDpsSo036394; Wed, 26 Mar 2003 14:51:55 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QDpFM3255344; Wed, 26 Mar 2003 14:51:20 +0100 Received: from gsine06.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39416 from ; Wed, 26 Mar 2003 14:51:07 +0100 Message-Id: <3E81B004.5932385E@hursley.ibm.com> Date: Wed, 26 Mar 2003 14:49:56 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: EricLKlein Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <006401c2f387$9acd8550$67061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, There are 35,184,372,088,832 48-bit prefixes available under the current IPv6 allocation scheme. I think that allows for a rather significant increase in the world population before we run out, or have to use the other 87.5% of the total address space. Address space is certainly no argument for private addresses. (Before anyone starts a side track, the fact that we have enough space doesn't automatically provide an allocation scheme or routeability, but those are separate issues.) Brian EricLKlein wrote: > > > > Done this way we will be defingin IPv7 real quick, as the unused > > > addresses > > > will add up very fast. > > > > There are a _lot_ of IPv6 routing prefixes, namely 281,474,976,710,656 > > (assuming every allocation is a /48 as is the current plan (last I > > heard)). Right now, there are about 120K routing prefixes in the > > Internet. I think IPv7 is a ways off. > > > > Not if we are assigning 200 addresses to each user (never to be reclaimed in > many cases) They touted IPv6 as 1 address per person in the world for years > to come. Look at the future. > > You will need (assumes modern western culture person other cultures may have > different requirements as defined by B. Gates): > 1 address per node on your computer (all must be registered as local > addresses are going away according to the list) > 1 address for your work computer + printer + other "smart" device > 1 address per hand held (Palm, IPaq, etc) > 1 address per cellular phone > 1 address per regular phone (possibly 1 per physical extension in your > house - but I think that can be avoided) > 1 address per appliance on your network - Refrigerator, dishwasher, air > conditioner, alarm system, car radio, etc (again all must be registered as > above) > and more address as they are used. > > This will make it a case of the person in 2000 who has 15 phone numbers for > their family of 4 changing to the person in 2005 who had 200 IP addresses > (or names that DNS to addresses) for their house plus 50 addresses for that > same family of 4. > > Some sort of local addresses space is a must. -------------------------------------------------------------------- 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 Mar 26 05:53:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QDrrVV002733; Wed, 26 Mar 2003 05:53:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QDrrHP002732; Wed, 26 Mar 2003 05:53:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QDroVV002722 for ; Wed, 26 Mar 2003 05:53:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QDrwcU017949 for ; Wed, 26 Mar 2003 05:53:58 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27366 for ; Wed, 26 Mar 2003 06:53:53 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:53:52 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:50:58 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:53:51 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:53:51 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2QDrKOI159918; Wed, 26 Mar 2003 14:53:46 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QDqqM3269286; Wed, 26 Mar 2003 14:52:54 +0100 Received: from gsine06.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA31510 from ; Wed, 26 Mar 2003 14:52:47 +0100 Message-Id: <3E81B06B.A010E558@hursley.ibm.com> Date: Wed, 26 Mar 2003 14:51:39 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Keith Moore Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <9224C664-5F39-11D7-8225-000393DB5366@cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, I haven't done an analysis, but it seems to me that deprecating site local is a significant simplification of the scoping problem, and thereby greatly increases the number of cases where the default algorithm will work. Brian Keith Moore wrote: > > > Multiple addresses per host are a real-world feature of IPv4 and have > > always been a design goal of IPv6. > > > > We've already defined the default address selection algorithm (RFC > > 3484). > > Applications are welcome to use a different algorithm, but they > > don't need to, which is why the default was defined. > > it's one thing to allow multiple addresses per host in the > architecture, quite another to expect hosts and apps to be able to > tolerate different addresses with different scopes and force them to > choose between these addresses in order to interoperate. > > the default address selection algorithm will only work in a fairly > narrow set of cases. > it's simply not the case that applications "don't need to" use a > different algorithm. -------------------------------------------------------------------- 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 Mar 26 05:56:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QDusVV002984; Wed, 26 Mar 2003 05:56:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QDurg6002983; Wed, 26 Mar 2003 05:56:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QDunVV002970 for ; Wed, 26 Mar 2003 05:56:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QDuwHP009607 for ; Wed, 26 Mar 2003 05:56:58 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAB29296 for ; Wed, 26 Mar 2003 06:56:53 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:56:52 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:53:56 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:56:49 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 13:56:49 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 1C88F8F86; Wed, 26 Mar 2003 14:56:45 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E0B5A8376; Wed, 26 Mar 2003 14:56:39 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 14:57:42 +0100 Organization: Unfix Message-Id: <003501c2f39f$ace89af0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <006f01c2f387$f70268e0$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QDuoVV002972 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > > >> IP's should be globably unique. Which will overcome many problems > > >> like network mergers ('oh we need to NAT now'), e2e problems etc. > > > The new address features of IPv6 should resolve this as easily as > > > changing > > > providers. > > > > What features are those? > > Autoconfiguration - IPV6 allows autoconfiguration of the > devices by either the router, DHCP server or both. > > This should resolve most of the problems when merging > networks, just change the part atthe front of the /64 (or /48) > address and leave the hosts the same. Make that /48 as that's what every endsite should be getting at a minimum. That's where the RFC is for. > SHould work the same as changing the ISP. That's what I thought too and is quite correct for a small network. But if one is going into a larger net (>50k hosts) you will also have the following administrativia to handle: - dns (forward AND reverse) - firewall configs - router configs (though one could propagate, but how secure is that) And then we are not even talking about telling the rest of the world that you are changing prefixes. Eg clueing in Verisign and others that your DNS servers changed. Seeing the fact that one can't even clue them in to make a AAAA glue in the gtld... no comment ;) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 06:08:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QE8MVV003667; Wed, 26 Mar 2003 06:08:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QE8M29003666; Wed, 26 Mar 2003 06:08:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QE8JVV003659 for ; Wed, 26 Mar 2003 06:08:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QE8ScU021396 for ; Wed, 26 Mar 2003 06:08:28 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23778 for ; Wed, 26 Mar 2003 06:08:22 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:08:21 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:08:21 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:08:21 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:08:20 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id B967A8F86; Wed, 26 Mar 2003 15:08:18 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 044AC7F0A; Wed, 26 Mar 2003 15:08:08 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 15:09:12 +0100 Organization: Unfix Message-Id: <003d01c2f3a1$47729110$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <016501c2f389$be32e1f0$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QE8JVV003660 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > > I don't like taking into account money in technical matters. > > > Welcome to the eral world, not the lab or academic world. Technicalities have nothing to do with money. The fact that one can't get their own TLA does somehow has to do with money though -> you are not big enough and you don't deserve a entry in the DFZ. > > BTW: let me note that I know of a certain hospital with a /16 IPv4 > > and all their heartmonitoring and other surveilance apparatus > > are using IP's out of that /16. With one big, good configured, > > firewall at the gate and ofcourse nice VLAN's which don't even > > allow packets from those VLAN's to come even close to the internet. > > Now I quickly hear a "why do they have a public /16", because it's > > globally unique and they can easily merge with another hospital > > or organization and don't have to 'fear/uncertainty/doubt' that > > their address spaces will ever collide. Oh and for the question > > of how much v6 they would need: a single /48 would suffice as > > it would allow 65535 networks or quite possibly VLAN's. And yes > > they could receive that from their current upstream which also > > delivers the /16 to their doorstep. > > > Your explination seems to take into account the pre IPv6 autoconfigure > options which are supposed to make this merger or provider > change eaiser to handle. Hmm are there any "pre IPv6 autoconfigure options" that make it easier? I can only name one: DHCP. Are there any others? Not that it matters much because renumbering is a pain even if you can change the prefix easily there are many other things one has to change. > They used the IPv4 space as they did > because there was nothing better, What would have been better than this? > but what we are supposed to be > doing is providing this bigger better plan. That address space is fully used, never checked out how much network connected computer equipment there is in a hospital? Also you might want to realize that Could you eloborate on 'bigger better plan'? Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 06:13:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEDNVV003841; Wed, 26 Mar 2003 06:13:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QEDNEc003840; Wed, 26 Mar 2003 06:13:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEDJVV003833 for ; Wed, 26 Mar 2003 06:13:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QEDScU022571 for ; Wed, 26 Mar 2003 06:13:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12360 for ; Wed, 26 Mar 2003 07:13:23 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:13:10 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:13:10 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:13:09 Z Received: from c001.snv.cp.net ([209.228.32.122] [209.228.32.122]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:13:09 Z Received: (cpmta 23759 invoked from network); 26 Mar 2003 06:13:07 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.122) with SMTP; 26 Mar 2003 06:13:07 -0800 X-Sent: 26 Mar 2003 14:13:07 GMT Message-Id: <01f501c2f3a2$081a5470$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <006401c2f387$9acd8550$67061eac@ttitelecom.com> <3E81B004.5932385E@hursley.ibm.com> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 16:14:32 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, I personally don't mind soo much when I am corrected publically in the list. But I do dislike it when I get multiple copies of the replies to me or to others. (In one case I got 4 copies of a single reply) Please only reply to the list, not to the message originator. Thanks, Eric -------------------------------------------------------------------- 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 Mar 26 06:36:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEaIVV004307; Wed, 26 Mar 2003 06:36:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QEaItB004306; Wed, 26 Mar 2003 06:36:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEaDVV004299 for ; Wed, 26 Mar 2003 06:36:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QEaLHP018640 for ; Wed, 26 Mar 2003 06:36:21 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04414 for ; Wed, 26 Mar 2003 07:36:10 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:34:15 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:34:15 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:34:05 Z Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:34:05 Z Received: from sdn-ap-030txhousp0277.dialsprint.net ([65.179.209.23] helo=cs.utk.edu) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yByV-0004Ke-00; Wed, 26 Mar 2003 06:33:55 -0800 Date: Wed, 26 Mar 2003 09:33:52 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com To: Naiming Shen From: Keith Moore In-Reply-To: <20030326053753.C0DC9508F08@prattle.redback.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As long as we are clear that, the "site-local" does not get special > treatment in terms of routing and dns, we should care less about if > "site-local" is deprecated or still lived. no. this is not sufficient. apps must not need to care about site-local either. nor is it acceptable to treat site-local as a security mechanism. > It's perfectly fine and > actually somewhat useful if "site-local" plays the same role as in > IPv4 addresses defined in rfc1918. no. rfc1918 has been a disaster. we need to learn from past mistakes, not repeat them. -------------------------------------------------------------------- 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 Mar 26 06:40:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEeNVV004384; Wed, 26 Mar 2003 06:40:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QEeMID004383; Wed, 26 Mar 2003 06:40:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEeIVV004376 for ; Wed, 26 Mar 2003 06:40:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QEeRHP019449 for ; Wed, 26 Mar 2003 06:40:27 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02310 for ; Wed, 26 Mar 2003 07:40:21 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:40:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:40:21 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:40:21 Z Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:40:20 Z Received: from sdn-ap-030txhousp0277.dialsprint.net ([65.179.209.23] helo=cs.utk.edu) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yC4d-0005FE-00; Wed, 26 Mar 2003 06:40:16 -0800 Date: Wed, 26 Mar 2003 09:40:13 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , , "'Kurt Erik Lindqvist'" , To: "EricLKlein" From: Keith Moore In-Reply-To: <017101c2f38a$35f59ac0$67061eac@ttitelecom.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, March 26, 2003, at 06:24 AM, EricLKlein wrote: >> Site-locals are useful, but the cost is too high. The additional >> complexity that site locals add to nearly every part of the Internet - >> in apps, DNS, routing, and elsewhere - simply isn't worth the benefit. > > How high is the cost of setting a standard that says the following 4 > prefixes are not broadcast over the Internet? It is one short rule in > all of > the systems no, that doesn't work. one reason why that doesn't work: applications and DNS are not aware of site boundaries, they don't know whether they are broadcasting a SL address over the Internet or not. >> There are less expensive ways to provide the same functionality. > > Could you name a few that take into account not having an ISP providing > addresses. yes, but wait until I get back from vacation. -------------------------------------------------------------------- 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 Mar 26 06:42:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEgdVV004471; Wed, 26 Mar 2003 06:42:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QEgdVW004470; Wed, 26 Mar 2003 06:42:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QEgZVV004463 for ; Wed, 26 Mar 2003 06:42:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QEghHP019919 for ; Wed, 26 Mar 2003 06:42:43 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08831 for ; Wed, 26 Mar 2003 07:42:35 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:42:28 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:42:27 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:42:27 Z Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 14:42:27 Z Received: from sdn-ap-030txhousp0277.dialsprint.net ([65.179.209.23] helo=cs.utk.edu) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yC6j-0000LP-00; Wed, 26 Mar 2003 06:42:25 -0800 Date: Wed, 26 Mar 2003 09:42:23 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , ipng@sunroof.eng.sun.com To: Brian E Carpenter From: Keith Moore In-Reply-To: <3E81B06B.A010E558@hursley.ibm.com> Message-Id: <27B16816-5F99-11D7-8225-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith, I haven't done an analysis, but it seems to me that deprecating > site local is a significant simplification of the scoping problem, > and thereby greatly increases the number of cases where the default > algorithm will work. I haven't done the analysis either, but intuitively, I think that's correct. however, I'm not confident that this is sufficient to allow address selection to work, at least not without identifying some other constraints in routing. -------------------------------------------------------------------- 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 Mar 26 07:08:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QF89VV004981; Wed, 26 Mar 2003 07:08:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QF89F3004980; Wed, 26 Mar 2003 07:08:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QF85VV004973 for ; Wed, 26 Mar 2003 07:08:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QF8EHP026128 for ; Wed, 26 Mar 2003 07:08:14 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14707 for ; Wed, 26 Mar 2003 07:08:08 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:08:07 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:07:26 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:07:26 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:07:25 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 08E0F8F86; Wed, 26 Mar 2003 16:07:22 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 858868376; Wed, 26 Mar 2003 16:07:16 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: "duplicate replies" (Was: RE: A use for site local addresses?) Date: Wed, 26 Mar 2003 16:08:20 +0100 Organization: Unfix Message-Id: <004f01c2f3a9$8a6fcac0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <01f501c2f3a2$081a5470$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > All, > > I personally don't mind soo much when I am corrected > publically in the list. > > But I do dislike it when I get multiple copies of the replies > to me or to > others. (In one case I got 4 copies of a single reply) > > Please only reply to the list, not to the message originator. Don't mind me correcting this point publicaly then as you will either have to fix up your Reply-To: or use a Followup-To: header. Though Followup-To is more for usenet ofcourse most clued email clients also know what to do with it. Note that your client is setting the Reply-To to you explicitly. Based upon that most clients and people will honor your 'request' :) I quote from the headers: 8<------------------------------ Message-Id: <01f501c2f3a2$081a5470$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: ------------------------------>8 So change that or don't whine about getting dupes. There are enough ways of avoiding them (Message-ID matching f.e.). Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 07:31:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFVIVV005232; Wed, 26 Mar 2003 07:31:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QFVIoh005231; Wed, 26 Mar 2003 07:31:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFVEVV005224 for ; Wed, 26 Mar 2003 07:31:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QFVNcU016209 for ; Wed, 26 Mar 2003 07:31:23 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15836 for ; Wed, 26 Mar 2003 08:31:17 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:31:17 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:31:14 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:31:13 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:31:13 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 726568F88; Wed, 26 Mar 2003 16:31:10 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4A6107F0A; Wed, 26 Mar 2003 16:31:00 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 16:32:03 +0100 Organization: Unfix Message-Id: <005701c2f3ac$da81cf60$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <017b01c2f38a$903cdf20$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QFVFVV005225 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: To keep in context this is what Naiming Shen wrote... > > As long as we are clear that, the "site-local" does not get special > > treatment in terms of routing and dns, we should care less about if > > "site-local" is deprecated or still lived. It's perfectly fine and > > actually somewhat useful if "site-local" plays the same role as in > > IPv4 addresses defined in rfc1918. > > The complete point behind IPv6 and 128 bit addresses is that we will get back what was once normal: End to End communication. And for that one needs globally unique IP's. If you imply site-locals this complete point is gone and then one can better stay with IPv4 and one big InterNAT. If you really want to have IP space for 'non-internet networks' then one should talk to the RIRs and request address space for this. This address space should then be divided in /48's and everyone who has a requirement for IPv6 address space and has a network which is not connected to the internet can request a /48 from that space. This will at least enforce global uniqueness. One should note that when one does connect to the internet this address space is futile as a single /48 cannot be announced into the DFZ and thus it will never ever be routable. Site-locals imply that networks will choose 'easy to remember' addresses and thus will cause dupes. And they won't be globally unique. > Or to ask it a different way, (and maybe this is the > solution) will all of the 10.x.x.x (and the other IPv4 > private addresses) suddenly become globally broadcast? Please define 'global broadcast' > > This is a bigger problem. What will an IPv6 application or > hardware do with a ::10.x.x.x address? >From a NetBSD's netstat -rn output (trimmed a bit): Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/104 ::1 UGRS 0 0 33220 lo0 => ::/96 ::1 UGRS 0 0 33220 lo0 => ::127.0.0.0/104 ::1 UGRS 0 0 33220 lo0 ::224.0.0.0/100 ::1 UGRS 0 0 33220 lo0 ::255.0.0.0/104 ::1 UGRS 0 0 33220 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 0 33220 lo0 2002::/24 ::1 UGRS 0 0 33220 lo0 2002:7f00::/24 ::1 UGRS 0 0 33220 lo0 2002:e000::/20 ::1 UGRS 0 0 33220 lo0 2002:ff00::/24 ::1 UGRS 0 0 33220 lo0 In other words: nullroute those 'special' blocks. Same goes for RFC1918 space btw. Afaik there is no BCP about this though. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 07:40:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFeiVV005500; Wed, 26 Mar 2003 07:40:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QFein4005499; Wed, 26 Mar 2003 07:40:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFefVV005492 for ; Wed, 26 Mar 2003 07:40:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QFeoHP005544 for ; Wed, 26 Mar 2003 07:40:50 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13283 for ; Wed, 26 Mar 2003 08:40:44 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:39:28 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:39:28 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:39:28 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:39:27 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 36E6C8F89; Wed, 26 Mar 2003 16:39:25 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4A34C8F67; Wed, 26 Mar 2003 16:39:15 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 16:40:18 +0100 Organization: Unfix Message-Id: <006101c2f3ae$022bf710$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <015b01c2f388$e1ad7ba0$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QFefVV005493 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > I agree, under the autoconfigure feature you should be able to do this > easily. Should. > Say that both networks were using the FE8::xxxx:xxxx network, > then one of them could change this to FE9::xxxx:xxxx prior to the merge, > and then just link them. > > Should be a piece of cake. An alternative would be simply to > go from both being FE8::xxxx:xxxx to one being FE8:1::xxxx:xxxx and > the other being FE8:2::xxxx:xxxx This way there would be the ability of > splitting sites and such by the thousands, and only using NAT for the > public Internet connections. And another Should. I suggest you use a lab setup with at least 50k hosts on both sides and then try and merge those networks. And please take into account that both netadmin groups don't like each others job to be taken over by the other folks, because 'the network was first ours and now we have to share' and that the external parties which administer the out-of-organization facilities aren't cooperating very well. Oh wait you will pay them a load of money ofcourse ;) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 07:44:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFihVV005664; Wed, 26 Mar 2003 07:44:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QFihCe005663; Wed, 26 Mar 2003 07:44:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFieVV005656 for ; Wed, 26 Mar 2003 07:44:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QFimHP006732 for ; Wed, 26 Mar 2003 07:44:48 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00461 for ; Wed, 26 Mar 2003 08:44:43 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:44:42 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:44:42 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:44:42 Z Received: from c001.snv.cp.net ([209.228.32.135] [209.228.32.135]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:44:41 Z Received: (cpmta 16997 invoked from network); 26 Mar 2003 07:44:38 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.135) with SMTP; 26 Mar 2003 07:44:38 -0800 X-Sent: 26 Mar 2003 15:44:38 GMT Message-Id: <026901c2f3ae$d0de64d0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <005701c2f3ac$da81cf60$210d640a@unfix.org> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 17:46:04 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Or to ask it a different way, (and maybe this is the >> solution) will all of the 10.x.x.x (and the other IPv4 >> private addresses) suddenly become globally broadcast? >Please define 'global broadcast' Think of it as if they were now suddenly 1::10:x:x:x, valid on the public internet, and "routable" even though they were private before. This is what I meant by "global" probably pore phrasing, but this example should show what I was asking. > > This is a bigger problem. What will an IPv6 application or > hardware do with a ::10.x.x.x address? > >From a NetBSD's netstat -rn output (trimmed a bit): > >Internet6: >Destination Gateway Flags Refs Use Mtu Interface >::/104 ::1 UGRS 0 0 33220 lo0 => >::/96 ::1 UGRS 0 0 33220 lo0 => >::127.0.0.0/104 ::1 UGRS 0 0 33220 lo0 >::224.0.0.0/100 ::1 UGRS 0 0 33220 lo0 >::255.0.0.0/104 ::1 UGRS 0 0 33220 lo0 >::ffff:0.0.0.0/96 ::1 UGRS 0 0 33220 lo0 >2002::/24 ::1 UGRS 0 0 33220 lo0 >2002:7f00::/24 ::1 UGRS 0 0 33220 lo0 >2002:e000::/20 ::1 UGRS 0 0 33220 lo0 >2002:ff00::/24 ::1 UGRS 0 0 33220 lo0 > >In other words: nullroute those 'special' blocks. >Same goes for RFC1918 space btw. Then what you are saying is the RFC 1918 private spaces are still private? -------------------------------------------------------------------- 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 Mar 26 07:49:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFnwVV005948; Wed, 26 Mar 2003 07:49:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QFnwjf005947; Wed, 26 Mar 2003 07:49:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFnqVV005933 for ; Wed, 26 Mar 2003 07:49:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QFo1cU021157 for ; Wed, 26 Mar 2003 07:50:01 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08087 for ; Wed, 26 Mar 2003 07:49:55 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:49:54 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:49:54 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:49:54 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:49:53 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 82F3B8F8A; Wed, 26 Mar 2003 16:49:51 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id A63108F67; Wed, 26 Mar 2003 16:49:46 +0100 (CET) From: "Jeroen Massar" To: "'David Conrad'" Cc: Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 16:50:50 +0100 Organization: Unfix Message-Id: <007901c2f3af$79d6ecb0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <9DBA686A-5F1F-11D7-BDFE-000393DB42B2@nominum.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QFnrVV005934 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Conrad [mailto:david.conrad@nominum.com] wrote: > Jeroen, > > On Tuesday, March 25, 2003, at 10:33 AM, Jeroen Massar wrote: > > Enduser ISP's will always charge for extra IP space as it's > > currently not customary to give an enduser more than 1 IP. > > Varies per service provider. My home ISP, for example, provides 2 > static addresses for the package I purchased. I frequently heard of > ISPs allocating /24s to customers, although that was a while back. Depends on a lot of things indeed. I could probably get more than one IP if I wanted to and paid for it. > > Also IPv4 is a becoming a 'scarce' resource. > > Of course, IANA just 'found' another 350 million unused addresses... Note that I quoted 'scarce', which is not for nothing, because indeed: http://www.iana.org/assignments/ipv4-address-space Quick grab, skipping the smaller leftovers: 58 - 60 reserved 70 - 79 reserved 83 - 126 reserved 197 reserved 224 - 239 multicast 240 - 255 reserved But the fact is that a country like China could use that space up with ease when they are going for mass GPRS mobile phones and other new toys that are under development. Also see HD ratio's. > > You might also realize that the current TLA policy for RIR's > > demands that you have 200 prospect clients. That is 200x /48. > > Aka 200 endusers on DSL will suffice for them. > > For those interested in address allocation policy, I might suggest > participating in the RIR public policy mailing lists and meetings > (ppml@arin.net and the upcoming Memphis meeting for those in the ARIN > region). Will do, thanks. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 07:50:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFo0VV005951; Wed, 26 Mar 2003 07:50:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QFo06A005950; Wed, 26 Mar 2003 07:50:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFnsVV005940 for ; Wed, 26 Mar 2003 07:49:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QFo2HP008453 for ; Wed, 26 Mar 2003 07:50:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01944 for ; Wed, 26 Mar 2003 08:49:56 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:49:54 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:46:51 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:49:45 Z Received: from c001.snv.cp.net ([209.228.32.139] [209.228.32.139]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:49:45 Z Received: (cpmta 15786 invoked from network); 26 Mar 2003 07:49:38 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.139) with SMTP; 26 Mar 2003 07:49:38 -0800 X-Sent: 26 Mar 2003 15:49:38 GMT Message-Id: <027501c2f3af$84431390$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <006101c2f3ae$022bf710$210d640a@unfix.org> Subject: Re: A use for site local addresses? Date: Wed, 26 Mar 2003 17:51:04 +0200 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Say that both networks were using the FE8::xxxx:xxxx network, >> then one of them could change this to FE9::xxxx:xxxx prior to the merge, >> and then just link them. >> >> Should be a piece of cake. An alternative would be simply to >> go from both being FE8::xxxx:xxxx to one being FE8:1::xxxx:xxxx and >> the other being FE8:2::xxxx:xxxx This way there would be the ability >>of >> splitting sites and such by the thousands, and only using NAT for the >> public Internet connections. >And another Should. >I suggest you use a lab setup with at least 50k hosts on both >sides and then try and merge those networks. And please take into >account that both netadmin groups don't like each others job to >be taken over by the other folks, because 'the network was first >ours and now we have to share' and that the external parties >which administer the out-of-organization facilities aren't >cooperating very well. Oh wait you will pay them a load of money >ofcourse ;) This is the same as the current problems. So how will you do it, have them both convert from the v4 10 net they are using to diffrent v6 addresses, and then they will play nice together? Someone mentioned not wanting to put money issues in a technicial discussion, but you have just shown that money and interpersonal issues are also a big issue here. These two guys who don't want to play nice will love having to convert to v6 and then merge, or changeing addresses because one of the companies is using a diffrent ISP so needs to change their block when then merge. Mostly I don't care what the resolution is, but we need to consider the mergers of 200 node companies not just the 50k ones. There are a lot more smaller than 50k networks out there than larger than 50k ones. -------------------------------------------------------------------- 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 Mar 26 07:54:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFsnVV006306; Wed, 26 Mar 2003 07:54:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QFsnl4006305; Wed, 26 Mar 2003 07:54:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QFsiVV006284 for ; Wed, 26 Mar 2003 07:54:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QFsrcU022527 for ; Wed, 26 Mar 2003 07:54:53 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17262 for ; Wed, 26 Mar 2003 08:54:43 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:54:40 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:54:35 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:54:35 Z Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 15:54:33 Z Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h2QFsIvm021981; Wed, 26 Mar 2003 07:54:18 -0800 (PST) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h2QFsH09021980; Wed, 26 Mar 2003 07:54:17 -0800 (PST) Date: Wed, 26 Mar 2003 07:54:17 -0800 From: Shannon -jj Behrens To: Jari Arkko Cc: "Bound, Jim" , Kurt Erik Lindqvist , ipng@sunroof.eng.sun.com Subject: Re: Mobility in Nodes Requirements Message-Id: <20030326155417.GA21701@alicia.nttmcl.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDCD@tayexc13.americas.cpqcorp.net> <3E80C7A8.1010309@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E80C7A8.1010309@kolumbus.fi> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 25, 2003 at 11:18:32PM +0200, Jari Arkko wrote: > * "Maybe you can list the mandatory components, but I don't > see a need to look at the optional ones." Well, how do I > know that if RFC nnnn isn't listed, its (a) optional or (b) > forgotten? I say we should be explicit and list the optional > components too. This is an interesting point. However, this begs the question of what to do when this document grows stale. Naturally, it will be tedious to update it with every new RFC. This is probably exacerbated by the fact that the list of optional RFC's will probably grow a lot faster than the list of required RFC's. If this document only listed required RFC's, it would probably be more stable and helpful in the long run. Hence, to answer your question: > Well, how do I > know that if RFC nnnn isn't listed, its (a) optional or (b) > forgotten? The answer would always be "optional". Best Regards, -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- 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 Mar 26 08:01:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QG1WVV006749; Wed, 26 Mar 2003 08:01:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QG1Vm1006748; Wed, 26 Mar 2003 08:01:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QG1SVV006741 for ; Wed, 26 Mar 2003 08:01:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QG1bcU025440 for ; Wed, 26 Mar 2003 08:01:37 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14872 for ; Wed, 26 Mar 2003 09:01:31 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:00:17 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:00:15 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:00:15 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:00:14 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA26031 for ; Wed, 26 Mar 2003 16:00:09 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA29532 for ; Wed, 26 Mar 2003 16:00:09 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2QG09t03832 for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:00:09 GMT Date: Wed, 26 Mar 2003 16:00:09 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030326160009.GS18295@ecs.soton.ac.uk> References: <015b01c2f388$e1ad7ba0$67061eac@ttitelecom.com> <006101c2f3ae$022bf710$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006101c2f3ae$022bf710$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Mar 26, 2003 at 04:40:18PM +0100, Jeroen Massar wrote: > I suggest you use a lab setup with at least 50k hosts on both > sides and then try and merge those networks. And please take into > account that both netadmin groups don't like each others job to > be taken over by the other folks, because 'the network was first > ours and now we have to share' and that the external parties > which administer the out-of-organization facilities aren't > cooperating very well. Oh wait you will pay them a load of money > ofcourse ;) > I think everybody is in agreement that in your typical IPv6 commercial or home deployment site-locals should not be used, the point is that there are other environments where site-locals have a legitimate use and which (imho) there has been no reasonable proposed alternative as of yet. Mike -------------------------------------------------------------------- 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 Mar 26 08:20:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGKIVV007350; Wed, 26 Mar 2003 08:20:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QGKI6u007349; Wed, 26 Mar 2003 08:20:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGKFVV007342 for ; Wed, 26 Mar 2003 08:20:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QGKOHP019229 for ; Wed, 26 Mar 2003 08:20:24 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12522 for ; Wed, 26 Mar 2003 08:20:16 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:18:57 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:18:56 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:18:56 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:18:53 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 26A808F8E; Wed, 26 Mar 2003 17:18:35 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 6DB238376; Wed, 26 Mar 2003 17:18:29 +0100 (CET) From: "Jeroen Massar" To: "'Mike Saywell'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 17:19:31 +0100 Organization: Unfix Message-Id: <009f01c2f3b3$7cd69b50$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030326160009.GS18295@ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QGKFVV007343 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: > I think everybody is in agreement that in your typical IPv6 commercial > or home deployment site-locals should not be used, the point > is that there are other environments where site-locals have a legitimate > use and which (imho) there has been no reasonable proposed alternative as of yet. Name those environments then. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 08:25:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGPOVV007502; Wed, 26 Mar 2003 08:25:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QGPOqM007499; Wed, 26 Mar 2003 08:25:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGPKVV007488 for ; Wed, 26 Mar 2003 08:25:20 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QGPTcU003221 for ; Wed, 26 Mar 2003 08:25:29 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17678 for ; Wed, 26 Mar 2003 08:25:22 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:25:22 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:22:27 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:25:21 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:25:20 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 125F18F8F; Wed, 26 Mar 2003 17:25:18 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 745AC8376; Wed, 26 Mar 2003 17:25:13 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 17:26:15 +0100 Organization: Unfix Message-Id: <00a701c2f3b4$6d7f7e50$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <026901c2f3ae$d0de64d0$67061eac@ttitelecom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > >> Or to ask it a different way, (and maybe this is the > >> solution) will all of the 10.x.x.x (and the other IPv4 > >> private addresses) suddenly become globally broadcast? > > >Please define 'global broadcast' > > Think of it as if they were now suddenly 1::10:x:x:x, valid > on the public > internet, and "routable" even though they were private > before. This is what > I meant by "global" probably pore phrasing, but this example > should show > what I was asking. 1:: ? I hope you meant what other people proposed as 2002::10.x.x.x which is just a direct map of IPv4's RFC1918 space of which 10/8 is one of them. > > This is a bigger problem. What will an IPv6 application or > > hardware do with a ::10.x.x.x address? > > > >From a NetBSD's netstat -rn output (trimmed a bit): > > > >Internet6: > >Destination Gateway Flags Refs Use Mtu Interface > >::/104 ::1 UGRS 0 0 33220 lo0 => > >::/96 ::1 UGRS 0 0 33220 lo0 => > >::127.0.0.0/104 ::1 UGRS 0 0 33220 lo0 > >::224.0.0.0/100 ::1 UGRS 0 0 33220 lo0 > >::255.0.0.0/104 ::1 UGRS 0 0 33220 lo0 > >::ffff:0.0.0.0/96 ::1 UGRS 0 0 33220 lo0 > >2002::/24 ::1 UGRS 0 0 33220 lo0 > >2002:7f00::/24 ::1 UGRS 0 0 33220 lo0 > >2002:e000::/20 ::1 UGRS 0 0 33220 lo0 > >2002:ff00::/24 ::1 UGRS 0 0 33220 lo0 > > > >In other words: nullroute those 'special' blocks. > >Same goes for RFC1918 space btw. > > Then what you are saying is the RFC 1918 private spaces are > still private? Why would those become routable all of a sudden? Better ask where boxes would actually route these as there really are no routing entries to these places because there are numberous organizations and individuals using this space. Also see RFC3056 section 5.9. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 08:25:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGPVVV007518; Wed, 26 Mar 2003 08:25:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QGPVod007517; Wed, 26 Mar 2003 08:25:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGPOVV007504 for ; Wed, 26 Mar 2003 08:25:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QGPXHP021094 for ; Wed, 26 Mar 2003 08:25:34 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10714 for ; Wed, 26 Mar 2003 08:25:28 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:25:19 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:25:19 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:25:18 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:25:17 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2QGP3OI107630 for ; Wed, 26 Mar 2003 17:25:07 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QGOtXl157014 for ; Wed, 26 Mar 2003 17:24:57 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49938 from ; Wed, 26 Mar 2003 17:24:45 +0100 Message-Id: <3E81D40B.294D44EF@hursley.ibm.com> Date: Wed, 26 Mar 2003 17:23:39 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <005701c2f3ac$da81cf60$210d640a@unfix.org> <026901c2f3ae$d0de64d0$67061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: ... > Then what you are saying is the RFC 1918 private spaces are still private? RFC 1918 hasn't been deprecated, if that's what you are asking. Brian -------------------------------------------------------------------- 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 Mar 26 08:38:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGcTVV008304; Wed, 26 Mar 2003 08:38:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QGcSBM008303; Wed, 26 Mar 2003 08:38:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGcPVV008296 for ; Wed, 26 Mar 2003 08:38:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QGcYcU007746 for ; Wed, 26 Mar 2003 08:38:34 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08578 for ; Wed, 26 Mar 2003 09:38:27 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:11 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:35:16 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:10 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:09 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h2QGYVdk009226 for ; Wed, 26 Mar 2003 17:35:34 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QGYHXl265786 for ; Wed, 26 Mar 2003 17:34:27 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51542 from ; Wed, 26 Mar 2003 17:34:11 +0100 Message-Id: <3E81D640.7AF964AA@hursley.ibm.com> Date: Wed, 26 Mar 2003 17:33:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <006101c2f3ae$022bf710$210d640a@unfix.org> <027501c2f3af$84431390$67061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > > >> Say that both networks were using the FE8::xxxx:xxxx network, > >> then one of them could change this to FE9::xxxx:xxxx prior to the merge, > >> and then just link them. > >> > >> Should be a piece of cake. An alternative would be simply to > >> go from both being FE8::xxxx:xxxx to one being FE8:1::xxxx:xxxx and > >> the other being FE8:2::xxxx:xxxx This way there would be the ability > >>of > >> splitting sites and such by the thousands, and only using NAT for the > >> public Internet connections. Regardless of the other comments made on this, it would be even simpler if both sites were using global address space. You could unite them straightforwardly using OSPF and you wouldn't need NAT. (You would need to unite the firewall rules as well, in any case.) Of course, this assumes multi6 comes up with a solution, but that is another discussion on another list. Brian -------------------------------------------------------------------- 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 Mar 26 08:39:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGdFVV008330; Wed, 26 Mar 2003 08:39:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QGdF0F008329; Wed, 26 Mar 2003 08:39:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QGdCVV008322 for ; Wed, 26 Mar 2003 08:39:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QGdKcU008029 for ; Wed, 26 Mar 2003 08:39:20 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21795 for ; Wed, 26 Mar 2003 09:39:14 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:35 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:03 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:03 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:02 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA26605 for ; Wed, 26 Mar 2003 16:38:01 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA02435 for ; Wed, 26 Mar 2003 16:38:01 GMT Received: (from ms@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2QGc1n05801 for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 16:38:01 GMT Date: Wed, 26 Mar 2003 16:38:01 +0000 From: Mike Saywell To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030326163801.GA3944@ecs.soton.ac.uk> References: <20030326160009.GS18295@ecs.soton.ac.uk> <009f01c2f3b3$7cd69b50$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009f01c2f3b3$7cd69b50$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Mar 26, 2003 at 05:19:31PM +0100, Jeroen Massar wrote: > Mike Saywell wrote: > > > I think everybody is in agreement that in your typical IPv6 commercial > > or home deployment site-locals should not be used, the point > > is that there are other environments where site-locals have a > legitimate > > use and which (imho) there has been no reasonable proposed alternative > as of yet. > > Name those environments then. Well off the top of my head... #1 An initially isolated ad-hoc network which is larger than a single subnet. The ad-hoc network may become attached to the global internet periodically, each time via a different ISP. One example of this could be on a boat which only gets global connectivty whilst in port. #2 (related) For an ad-hoc network to auto-config it needs an address range to use. It's extremely limiting to confine them to a single subnet. #3 (to be found at the root of this thread) A provider independant (i.e. no upstream ISP) network which aims to provide transit between 2 or more networks (which may or may not be public). I'm sure there are many others... Mike -------------------------------------------------------------------- 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 Mar 26 09:00:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QH0qVV009158; Wed, 26 Mar 2003 09:00:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QH0qY7009157; Wed, 26 Mar 2003 09:00:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QH0mVV009150 for ; Wed, 26 Mar 2003 09:00:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QH0vcU016093 for ; Wed, 26 Mar 2003 09:00:57 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08647 for ; Wed, 26 Mar 2003 10:00:51 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:00:36 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:00:36 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:00:35 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:00:30 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2QH0KS05649; Wed, 26 Mar 2003 19:00:20 +0200 Date: Wed, 26 Mar 2003 19:00:19 +0200 (EET) From: Pekka Savola To: Jeroen Massar cc: "'EricLKlein'" , Subject: RE: A use for site local addresses? In-Reply-To: <00a701c2f3b4$6d7f7e50$210d640a@unfix.org> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Mar 2003, Jeroen Massar wrote: > > >> Or to ask it a different way, (and maybe this is the > > >> solution) will all of the 10.x.x.x (and the other IPv4 > > >> private addresses) suddenly become globally broadcast? > > > > >Please define 'global broadcast' > > > > Think of it as if they were now suddenly 1::10:x:x:x, valid > > on the public > > internet, and "routable" even though they were private > > before. This is what > > I meant by "global" probably pore phrasing, but this example > > should show > > what I was asking. > > 1:: ? I hope you meant what other people proposed as > 2002::10.x.x.x which is just a direct map of IPv4's > RFC1918 space of which 10/8 is one of them. There's a caveat to using 2002:FOO (where FOO is in private address space). If any implementation in the network has 6to4 pseudo-interface enabled, the packets it sends in that network will be blackholed. Not necessarily a bad thing, but one has to be careful when proclaiming it as a solution. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 26 09:23:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHNoVV009893; Wed, 26 Mar 2003 09:23:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QHNoc2009892; Wed, 26 Mar 2003 09:23:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHNkVV009885 for ; Wed, 26 Mar 2003 09:23:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QHNtHP011472 for ; Wed, 26 Mar 2003 09:23:55 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01543 for ; Wed, 26 Mar 2003 10:23:46 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:22:00 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:21:08 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:21:08 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:21:07 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2QHL3So077284 for ; Wed, 26 Mar 2003 18:21:04 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QHL1Xl094712 for ; Wed, 26 Mar 2003 18:21:02 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35094 from ; Wed, 26 Mar 2003 18:20:58 +0100 Message-Id: <3E81E138.BB784E24@hursley.ibm.com> Date: Wed, 26 Mar 2003 18:19:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <20030326160009.GS18295@ecs.soton.ac.uk> <009f01c2f3b3$7cd69b50$210d640a@unfix.org> <20030326163801.GA3944@ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Mike Saywell wrote: > > On Wed, Mar 26, 2003 at 05:19:31PM +0100, Jeroen Massar wrote: > > Mike Saywell wrote: > > > > > I think everybody is in agreement that in your typical IPv6 commercial > > > or home deployment site-locals should not be used, the point > > > is that there are other environments where site-locals have a > > legitimate > > > use and which (imho) there has been no reasonable proposed alternative > > as of yet. > > > > Name those environments then. > > Well off the top of my head... > > #1 > An initially isolated ad-hoc network which is larger than a single > subnet. The ad-hoc network may become attached to the global internet > periodically, each time via a different ISP. One example of this could > be on a boat which only gets global connectivty whilst in port. > > #2 (related) > For an ad-hoc network to auto-config it needs an address range to use. > It's extremely limiting to confine them to a single subnet. > > #3 (to be found at the root of this thread) > A provider independant (i.e. no upstream ISP) network which aims to > provide transit between 2 or more networks (which may or may not be > public). > Any address space is private if you choose not to announce a route to it. So any address space that you can get legitimately will satisify these requirements. Although 6to4 space was designed for something else, as people have pointed out, it can be used this way, if you can't get a normal global prefix. We may well need an allocation mechanism for PI prefixes, known to be unrouteable in general, but that is another thread. Brian -------------------------------------------------------------------- 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 Mar 26 09:37:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHbKVV010330; Wed, 26 Mar 2003 09:37:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QHbK4w010329; Wed, 26 Mar 2003 09:37:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHbGVV010318 for ; Wed, 26 Mar 2003 09:37:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QHbPHP016501 for ; Wed, 26 Mar 2003 09:37:25 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10275 for ; Wed, 26 Mar 2003 10:37:20 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:37:04 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:37:04 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:37:04 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:37:03 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A3C18137F09; Wed, 26 Mar 2003 09:37:02 -0800 (PST) Date: Wed, 26 Mar 2003 09:37:02 -0800 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "EricLKlein" From: David Conrad In-Reply-To: <006f01c2f387$f70268e0$67061eac@ttitelecom.com> Message-Id: <8DBE3E5E-5FB1-11D7-BCE2-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, On Wednesday, March 26, 2003, at 03:07 AM, EricLKlein wrote: >>> The new address features of IPv6 should resolve this as easily as >>> changing providers. >> What features are those? > Autoconfiguration - IPV6 allows autoconfiguration of the devices by > either > the router, DHCP server or both. And how will autoconfiguring a particular device affect the firewall filters and other related configurations? How will I be able to autoconfigure (say) the DNS server(s), the DHCP server(s), or the routers throughout the entire site's infrastructure? > This should resolve most of the problems when merging networks, just > change > the part atthe front of the /64 (or /48) address and leave the hosts > the > same. I suspect you are underestimating the difficulty of renumbering and overestimating the level of clue of people asked to do the renumbering. Rgds, -drc -------------------------------------------------------------------- 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 Mar 26 09:38:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHcQVV010371; Wed, 26 Mar 2003 09:38:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QHcQpM010370; Wed, 26 Mar 2003 09:38:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHcLVV010360 for ; Wed, 26 Mar 2003 09:38:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QHcUHP016861 for ; Wed, 26 Mar 2003 09:38:30 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26007 for ; Wed, 26 Mar 2003 10:38:25 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:38:24 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:38:24 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:38:24 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:38:24 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5F3108F99; Wed, 26 Mar 2003 18:38:21 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 972658376; Wed, 26 Mar 2003 18:38:16 +0100 (CET) From: "Jeroen Massar" To: "'Mike Saywell'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 18:39:19 +0100 Organization: Unfix Message-Id: <00ba01c2f3be$a207ef40$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030325233008.GR18295@ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QHcMVV010361 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: > On Tue, Mar 25, 2003 at 11:51:24PM +0100, Jeroen Massar wrote: > > To sum up, the only reasons I have seen so far and please add to > > list if I miss a couple, which is quite probable and very much > > related to NATs, which are being discussed for deprecation also... > Well, there's my original reason... > > - My network is operator independant but I'm not a multi-national > company or an ISP (thus not in a position to obtain address space > directly from a registry). Sitelocals have nothing to do with this, as you apparently want globally reachable address space. Effectively this means you are an endsite, thus get space from you upstream. And the real solution for you lies in Multihoming to make sure your operator independency is guaranteed. > Also... > > - Ad-hoc networks become restricted to link local addresses and thus > a single flat subnet. > > The latter is perhaps covered by the appendix in the draft, but I do > not beleive the former has been addressed. This is indeed mostly covered by the appendix. I actually rather see a seperate: 'disjunct non-globaly routable address registry' as a solution here. Eg a RIR where one can request space from the site local addresses. Thus making them at least globally unique. I do see a reason for that kind of address space. But basically this is the same for ASn's, MAC's, EUI-64 and IPv4 space. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 09:40:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHeEVV010427; Wed, 26 Mar 2003 09:40:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QHeEVh010426; Wed, 26 Mar 2003 09:40:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHeBVV010419 for ; Wed, 26 Mar 2003 09:40:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QHeJcU002131 for ; Wed, 26 Mar 2003 09:40:20 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23637 for ; Wed, 26 Mar 2003 09:40:14 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:40:13 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:40:10 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:40:09 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:40:09 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA18277; Wed, 26 Mar 2003 09:40:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2QHe6507935; Wed, 26 Mar 2003 09:40:06 -0800 X-mProtect: <200303261740> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2pt1Jj; Wed, 26 Mar 2003 09:40:05 PST Message-Id: <3E81E5F5.572CAFFA@iprg.nokia.com> Date: Wed, 26 Mar 2003 09:40:05 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft References: <20030326114233.12CAA791@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Itojun, Jun-ichiro itojun Hagino wrote: > how can you prevent random other node to assign P::X (which you are > using and verified fe80::X by DAD) on the interface? DIID does not > work in practice. That's not supposed to happen, because the other node would be prevented from autoconfiguring the corresponding link-local address. Perhaps you are suggesting that bad things can happen if nodes do not do DAD, or exhibit some other protocol violation. In that case I would agree with you, but I don't think that is a suitable basis for making such decisions. I am in the group that believes DIID is a (far!) better solution. It is certainly more scalable, and it retrieves for our future benefit the ability to use many routing prefixes on the same link. Regards, Charlie P. -------------------------------------------------------------------- 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 Mar 26 09:43:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHhDVV010696; Wed, 26 Mar 2003 09:43:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QHhDPf010695; Wed, 26 Mar 2003 09:43:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHh9VV010685 for ; Wed, 26 Mar 2003 09:43:09 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QHhIHP018613 for ; Wed, 26 Mar 2003 09:43:18 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19846 for ; Wed, 26 Mar 2003 09:43:12 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:43:00 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:43:00 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:42:59 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:42:59 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Mar 2003 09:42:56 -0800 Reply-To: From: "Tony Hain" To: Cc: "'Bob Hinden & Margaret Wasserman'" Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 09:42:48 -0800 Message-Id: <047c01c2f3bf$1dbc7bb0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <13E98A20-5F39-11D7-8225-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QHh9VV010687 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > It wasn't a few vocal people. It was an overwhelming > majority. There > were far more people in favor of deprecating site locals at that > meeting, than the set of people in favor of site locals even if you > include those on the list those who weren't present at that meeting. > It was a clear consensus of the working group. And yes, you > can make a > decision in a face-to-face meeting if there is such overwhelming > support for the decision at the meeting that there simply > aren't enough > people on the mailing list to affect the consensus. There are significantly more people on this list than you could fit in one of the rooms in SF. The chairs need to raise the question on the list, because this is not a trival issue. From reports I heard the whole SF discussion was based on a bogus assertion that SL == NAT. > > > Site-locals are useful exactly for the case that started > this thread, > > Site-locals are useful, but the cost is too high. The additional > complexity that site locals add to nearly every part of the > Internet - > in apps, DNS, routing, and elsewhere - simply isn't worth the > benefit. > There are less expensive ways to provide the same functionality. If they exist then list them. There is currently no other way to provide disconnected sites address space. There is no other way to provide stable internal use addresses for intermittently connected sites. There is no other way to provide consistent consumer-simple route filtering for local use appliances and applications. The cost of allowing niche applications to drive the overall architecture is too high. The mainstream applications will be consumer oriented plug-n-play, so the addressing architecture has to take that into account. Yes that means some apps will have to go out of their way to specify a global scope address, but that is not a high cost, and it is limited to the app developer. See if you can figure out a way for Joe-sixpack to restrict the use of some applications on a machine to local use while others are global use, using only global addresses. For the consumer space, the only reasonable way to make this work is to have the restricted apps use a restricted address space that the ISPs know to filter. Tony > > Keith > -------------------------------------------------------------------- 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 Mar 26 09:57:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHvoVV011468; Wed, 26 Mar 2003 09:57:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QHvoIu011467; Wed, 26 Mar 2003 09:57:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QHvlVV011460 for ; Wed, 26 Mar 2003 09:57:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QHvuHP024388 for ; Wed, 26 Mar 2003 09:57:56 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28277 for ; Wed, 26 Mar 2003 10:57:50 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:57:49 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:57:49 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:57:49 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 17:57:48 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2QHwdVj013967; Wed, 26 Mar 2003 19:58:40 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2QHwair013966; Wed, 26 Mar 2003 19:58:36 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: DAD in node requirements draft From: Mika Liljeberg To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20030326114233.12CAA791@starfruit.itojun.org> References: <20030326114233.12CAA791@starfruit.itojun.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048701515.11083.19.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Mar 2003 19:58:36 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2003-03-26 at 13:42, Jun-ichiro itojun Hagino wrote: > >> note the mechanism is called DAD not DIID. this has > >> been discussed to death numerous times, please refer to the archive. > >I know. Means people still disagree about it. > > how can you prevent random other node to assign P::X (which you are > using and verified fe80::X by DAD) on the interface? If X is a new ID for the other node, it would have to do DAD with fe80::X. If the node alrady owns X, it could skip the DAD. In any case, I defend my id X against all possible prefix::X, so the other node will no be able to take it no matter what prefix it uses. > DIID does not work in practice. It does work if everyone follows the same rules. Besides, if you do DAD for every address, a new prefix appearing in a RA will cause a DAD storm as every node on the link will attempt to configure a new address at the same time. MikaL -------------------------------------------------------------------- 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 Mar 26 10:07:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QI75VV011976; Wed, 26 Mar 2003 10:07:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QI75rA011975; Wed, 26 Mar 2003 10:07:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QI72VV011968 for ; Wed, 26 Mar 2003 10:07:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QI7BHP028040 for ; Wed, 26 Mar 2003 10:07:11 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16481 for ; Wed, 26 Mar 2003 10:07:05 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:07:05 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:05:59 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:05:58 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:05:58 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2QI5tD06476; Wed, 26 Mar 2003 20:05:55 +0200 Date: Wed, 26 Mar 2003 20:05:54 +0200 (EET) From: Pekka Savola To: Tony Hain cc: ipng@sunroof.eng.sun.com, "'Bob Hinden & Margaret Wasserman'" Subject: RE: A use for site local addresses? In-Reply-To: <047c01c2f3bf$1dbc7bb0$ee1a4104@eagleswings> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Mar 2003, Tony Hain wrote: > Keith Moore wrote: > > It wasn't a few vocal people. It was an overwhelming > > majority. There > > were far more people in favor of deprecating site locals at that > > meeting, than the set of people in favor of site locals even if you > > include those on the list those who weren't present at that meeting. > > It was a clear consensus of the working group. And yes, you > > can make a > > decision in a face-to-face meeting if there is such overwhelming > > support for the decision at the meeting that there simply > > aren't enough > > people on the mailing list to affect the consensus. > > There are significantly more people on this list than you could fit in > one of the rooms in SF. The chairs need to raise the question on the > list, because this is not a trival issue. I certainly support asking the list.. > From reports I heard the whole > SF discussion was based on a bogus assertion that SL == NAT. .. but this is not true. In fact, (AFAIR) few arguments centered around the fear of NAT. When the choice was between "limited use" and "deprecate", I guess this argument was mentioned -- but then the question was only about how SL is going to be "put down" (ie. which kind of message would be sent). People didn't see the need for RFC1918 space in IPv6. I don't like SL myself, but I was surprised to see people wanted even more harsh action than I had anticipated, based on the IMO dangerous direction we went in Atlanta. My guess would be that there was new application/operator perspective to the dialogue, and after writing a few drafts and revisions, folks seemed to start realizing that actually making site-locals *work* (to some definition of "work") would be going to be *painful*. I personally have struggled with at least one specification (SSM multicast architecture) in the meantime -- and if we'd have to specify the scoping treatment in all the specs for basically everything related to routing, and even further in applications etc., I'd probably start crying. *Not* worth the effort. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 26 10:24:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIOHVV012425; Wed, 26 Mar 2003 10:24:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QIOHK6012424; Wed, 26 Mar 2003 10:24:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIOEVV012417 for ; Wed, 26 Mar 2003 10:24:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QIOMcU020546 for ; Wed, 26 Mar 2003 10:24:23 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10094 for ; Wed, 26 Mar 2003 11:24:17 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:24:13 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:24:13 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:24:13 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:24:12 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id CFCEF8F9F; Wed, 26 Mar 2003 19:24:10 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D41EA8F67; Wed, 26 Mar 2003 19:23:59 +0100 (CET) From: "Jeroen Massar" To: "'Pekka Savola'" Cc: Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 19:25:02 +0100 Organization: Unfix Message-Id: <00ca01c2f3c5$056817d0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola [mailto:pekkas@netcore.fi] wrote: > On Wed, 26 Mar 2003, Jeroen Massar wrote: > > > >> Or to ask it a different way, (and maybe this is the > > > >> solution) will all of the 10.x.x.x (and the other IPv4 > > > >> private addresses) suddenly become globally broadcast? > > > > > > >Please define 'global broadcast' > > > > > > Think of it as if they were now suddenly 1::10:x:x:x, valid > > > on the public > > > internet, and "routable" even though they were private > > > before. This is what > > > I meant by "global" probably pore phrasing, but this example > > > should show > > > what I was asking. > > > > 1:: ? I hope you meant what other people proposed as > > 2002::10.x.x.x which is just a direct map of IPv4's > > RFC1918 space of which 10/8 is one of them. > > There's a caveat to using 2002:FOO (where FOO is in private address > space). If any implementation in the network has 6to4 > pseudo-interface enabled, the packets it sends in that > network will be blackholed. Good point. > Not necessarily a bad thing, but one has to be careful when > proclaiming it as a solution. That's why I'd rather see a /32 or something out of which organisations can request space (/48's) for non-internet connected networks. Because the /48's will be too scattered around the world and only /35's or bigger are allowed in the DFZ at this moment this would also make sure that nobody will route between them over the global inet. But they are globally unique which overcomes all the "we will need NAT because we are merging" and other problems. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 10:44:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIiTVV012746; Wed, 26 Mar 2003 10:44:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QIiTwL012745; Wed, 26 Mar 2003 10:44:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIiPVV012737 for ; Wed, 26 Mar 2003 10:44:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QIiYHP013210 for ; Wed, 26 Mar 2003 10:44:34 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13088 for ; Wed, 26 Mar 2003 11:44:22 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:44:05 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:41:10 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:44:04 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:44:03 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 173C48FA3; Wed, 26 Mar 2003 19:44:01 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5A8CF8F5C; Wed, 26 Mar 2003 19:43:56 +0100 (CET) From: "Jeroen Massar" To: "'Mike Saywell'" , Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 19:44:59 +0100 Organization: Unfix Message-Id: <00d201c2f3c7$ce3e0e10$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030326163801.GA3944@ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QIiQVV012738 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: > On Wed, Mar 26, 2003 at 05:19:31PM +0100, Jeroen Massar wrote: > > Mike Saywell wrote: > > > > > I think everybody is in agreement that in your typical IPv6 commercial > > > or home deployment site-locals should not be used, the point > > > is that there are other environments where site-locals have a legitimate > > > use and which (imho) there has been no reasonable proposed alternative > > > as of yet. > > > > Name those environments then. > > Well off the top of my head... > > #1 > An initially isolated ad-hoc network which is larger than a single > subnet. The ad-hoc network may become attached to the global internet > periodically, each time via a different ISP. One example of > this could be on a boat which only gets global connectivty whilst in port. That's a good example. The boat could use a /48, at least I think most cruisers need something similar like that size, from their office allocation. Eg "The Boat Company" requests 2 /48's from their office upstream and use one of them for their boat. If they have more than 200 boats they could even go for a TLA, though I doubt you can convince a RIR that a boat is a client and that they really need that much space. Btw: Geographical based multihoming won't work, unless there is Sea-Geo ;) > #2 (related) > For an ad-hoc network to auto-config it needs an address range to use. > It's extremely limiting to confine them to a single subnet. > > #3 (to be found at the root of this thread) > A provider independant (i.e. no upstream ISP) network which aims to > provide transit between 2 or more networks (which may or may not be > public). Effectively all these three boil down to one thing: - globally unique addresses - not connected to the internet A place to register globally unique, but non-internet-connected address space would be the best place IMHO. This will take quite some effort but it is quite probably the best way to avoid problems like mergers. > I'm sure there are many others... If we can't identify them, we can't have a solution for them. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 10:49:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIndVV012917; Wed, 26 Mar 2003 10:49:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QIndAe012916; Wed, 26 Mar 2003 10:49:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QInaVV012906 for ; Wed, 26 Mar 2003 10:49:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QInicU000364 for ; Wed, 26 Mar 2003 10:49:45 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29147 for ; Wed, 26 Mar 2003 11:49:39 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:49:38 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:46:43 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:49:38 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:49:37 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2QInaSo073214 for ; Wed, 26 Mar 2003 19:49:36 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QInY22270434 for ; Wed, 26 Mar 2003 19:49:35 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34314 from ; Wed, 26 Mar 2003 19:49:33 +0100 Message-Id: <3E81F5FB.594D3810@hursley.ibm.com> Date: Wed, 26 Mar 2003 19:48:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <047c01c2f3bf$1dbc7bb0$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > ... From reports I heard the whole > SF discussion was based on a bogus assertion that SL == NAT. I think the point was more that by eliminating a whole layer of complexity from the scoping rules, we resolve the whole bunch of problems generated by all the usage models for SLs. I agree that this is orthogonal to NAT. Brian -------------------------------------------------------------------- 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 Mar 26 10:58:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIwkVV013353; Wed, 26 Mar 2003 10:58:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QIwj7G013352; Wed, 26 Mar 2003 10:58:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIwgVV013342 for ; Wed, 26 Mar 2003 10:58:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QIwocU003878 for ; Wed, 26 Mar 2003 10:58:50 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19724 for ; Wed, 26 Mar 2003 11:58:07 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:57:56 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:57:47 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:57:47 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:57:47 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Mar 2003 10:57:46 -0800 Reply-To: From: "Tony Hain" To: "'Pekka Savola'" Cc: , "'Bob Hinden & Margaret Wasserman'" Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 10:57:46 -0800 Message-Id: <048601c2f3c9$97311eb0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QIwgVV013344 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > People didn't see the need for RFC1918 space in IPv6. Just like they didn't see the need for private address space in IPv4 until there were massive deployments of whatever random numbers people found in documents. For those who have forgotten, private address space was not set aside to support NAT, it exists to provide space for disconnected networks, that won't collide with existing allocations when those attach. NAT came along later and took advantage of the existence of private space. There is a need for address space for disconnected networks. If the argument is to set aside a different set of address space and define it as unroutable, what is the point? We already have a defined unroutable space, what value does a different one add? Any issues that are raised for FEC0:: will hold for whatever new space gets defined. Tony -------------------------------------------------------------------- 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 Mar 26 10:59:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIxbVV013397; Wed, 26 Mar 2003 10:59:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QIxbkP013396; Wed, 26 Mar 2003 10:59:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QIxXVV013386 for ; Wed, 26 Mar 2003 10:59:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QIxgcU004248 for ; Wed, 26 Mar 2003 10:59:42 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07125 for ; Wed, 26 Mar 2003 11:59:36 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:59:36 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:56:41 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:59:35 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 18:59:35 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21668; Wed, 26 Mar 2003 10:59:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2QIxXv15243; Wed, 26 Mar 2003 10:59:33 -0800 X-mProtect: <200303261859> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVvlgTC; Wed, 26 Mar 2003 10:59:32 PST Message-Id: <3E81FA05.9010109@iprg.nokia.com> Date: Wed, 26 Mar 2003 11:05:41 -0800 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeroen Massar CC: "'Mike Saywell'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <00d201c2f3c7$ce3e0e10$210d640a@unfix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeroen Massar wrote: > Mike Saywell wrote: >>#2 (related) >>For an ad-hoc network to auto-config it needs an address range to use. >>It's extremely limiting to confine them to a single subnet. >> >>#3 (to be found at the root of this thread) >>A provider independant (i.e. no upstream ISP) network which aims to >>provide transit between 2 or more networks (which may or may not be >>public). > > > Effectively all these three boil down to one thing: > - globally unique addresses > - not connected to the internet > > A place to register globally unique, but non-internet-connected > address space would be the best place IMHO. > This will take quite some effort but it is quite probably the > best way to avoid problems like mergers. In the case of the cruise ship, it makes sense for the ship to "own" a globally unique prefix. But, in the pure ad-hoc case, all nodes are peers and may be drawn from completely unrelated interest groups/geographies. In this case, you need to ask: "who owns the globally unique prefix?" and "what happens if the prefix owner goes away?". (I'm perfectly happy if these questions can be answered w/o site-locals, BTW.) Fred ftemplin@iprg.nokia.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 Mar 26 11:05:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ5GVV013804; Wed, 26 Mar 2003 11:05:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJ5Gkb013800; Wed, 26 Mar 2003 11:05:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ5CVV013786 for ; Wed, 26 Mar 2003 11:05:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJ5LcU006837 for ; Wed, 26 Mar 2003 11:05:21 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12197 for ; Wed, 26 Mar 2003 12:05:15 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:05:15 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:05:15 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:05:15 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:05:14 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Mar 2003 11:05:13 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F50455E7@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLzuyOp0f8jToc4Sr6O3fFnzheBIAAD0M/g From: "Michel Py" To: "Pekka Savola" , "Jeroen Massar" Cc: "EricLKlein" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QJ5CVV013787 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There's a caveat to using 2002:FOO (where FOO is in private > address space). If any implementation in the network has > 6to4 pseudo-interface enabled, the packets it sends in that > network will be blackholed. > Not necessarily a bad thing, but one has to be careful when > proclaiming it as a solution. I don't proclaim it a solution..... I was just trying to find a way out of hijacking a real prefix which is what people did before RFC1594. Michel. -------------------------------------------------------------------- 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 Mar 26 11:06:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ6MVV013916; Wed, 26 Mar 2003 11:06:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJ6MF9013915; Wed, 26 Mar 2003 11:06:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ6IVV013903 for ; Wed, 26 Mar 2003 11:06:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJ6RHP022308 for ; Wed, 26 Mar 2003 11:06:27 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09135 for ; Wed, 26 Mar 2003 11:06:21 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:06:17 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:06:17 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:06:16 Z Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:06:16 Z Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 23549137F09 for ; Wed, 26 Mar 2003 11:06:15 -0800 (PST) Date: Wed, 26 Mar 2003 11:06:14 -0800 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: David Conrad To: Content-Transfer-Encoding: 7bit In-Reply-To: <006401c2f387$9acd8550$67061eac@ttitelecom.com> Message-Id: <041DAA34-5FBE-11D7-BCE2-000393DB42B2@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, > Not if we are assigning 200 addresses to each user (never to be > reclaimed in > many cases) They touted IPv6 as 1 address per person in the world for > years > to come. I don't think you are grasping the scale of the IPv6 address space. A little simple math (that I'm sure I'll get wrong :-)): According to the US Census bureau: - Estimated world population as of 3/26/03, 17:40:10 GMT+5: 6,282,814,548 - Estimated world population in 2050: ~9,000,000,000 Taking Brian's number (35,184,372,088,832 or 2^45) for the number of /48s currently available for assignment according to the RFCs today, you get: - 5600 /48s per person today - 3909 /48s per person in 2050 Note that those are /48s (each capable of addressing 64K /64s or, if you want ignore the autoconfiguration goop that eats the lower 64, 1,208,925,819,614,629,174,706,176 /128s). A bit more than 1 address per person in the world. And that's just one format specifier. (Not that this matters, we can't even route 0.001% of Brian's number, but that's a rant for another time) Arguing for site locals on the basis of conservation of address space is a waste of time, regardless of the validity of those arguments -- IPv6 address quantities are just too big. Where private addressing (including site locals) could conceivably have value is: - removing the need to deal with the address allocation bureaucracy/cost; - removing concerns about provider lock-in due to costs of renumbering. One of the downsides of site locals is the same downside you get with 1918 space -- merge two companies using private address space and you'll probably have to deal with address space collisions, forcing one of the two to renumber. Much easier and simpler to simply allocate (potentially non-routed) globally unique /48s to everybody that asks. Note that last sentence well. Rgds, -drc -------------------------------------------------------------------- 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 Mar 26 11:06:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ6qVV013948; Wed, 26 Mar 2003 11:06:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJ6qJM013947; Wed, 26 Mar 2003 11:06:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ6kVV013931 for ; Wed, 26 Mar 2003 11:06:47 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJ6tHP022532 for ; Wed, 26 Mar 2003 11:06:55 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04374 for ; Wed, 26 Mar 2003 11:06:50 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:06:50 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:03:55 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:06:49 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:06:49 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Mar 2003 11:06:48 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F50455E8@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLzv9BHTjA78mLDSkOkeKmyCX0iMgACuvGA From: "Michel Py" To: "David Conrad" , "EricLKlein" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QJ6lVV013932 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > David Conrad wrote: > I suspect you are underestimating the difficulty of > renumbering and overestimating the level of clue of > people asked to do the renumbering. Agree. Michel. -------------------------------------------------------------------- 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 Mar 26 11:09:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ9YVV014179; Wed, 26 Mar 2003 11:09:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJ9YLY014177; Wed, 26 Mar 2003 11:09:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJ9UVV014163 for ; Wed, 26 Mar 2003 11:09:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJ9dcU008617 for ; Wed, 26 Mar 2003 11:09:39 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15616 for ; Wed, 26 Mar 2003 12:09:33 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:09:33 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:09:33 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:09:32 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:09:32 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2QJ9RU07075; Wed, 26 Mar 2003 21:09:27 +0200 Date: Wed, 26 Mar 2003 21:09:27 +0200 (EET) From: Pekka Savola To: Tony Hain cc: ipng@sunroof.eng.sun.com, "'Bob Hinden & Margaret Wasserman'" Subject: RE: A use for site local addresses? In-Reply-To: <048601c2f3c9$97311eb0$ee1a4104@eagleswings> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Mar 2003, Tony Hain wrote: > Pekka Savola wrote: > > People didn't see the need for RFC1918 space in IPv6. > > Just like they didn't see the need for private address space in IPv4 > until there were massive deployments of whatever random numbers people > found in documents. For those who have forgotten, private address space > was not set aside to support NAT, it exists to provide space for > disconnected networks, that won't collide with existing allocations when > those attach. NAT came along later and took advantage of the existence > of private space. > > There is a need for address space for disconnected networks. If the > argument is to set aside a different set of address space and define it > as unroutable, what is the point? We already have a defined unroutable > space, what value does a different one add? Any issues that are raised > for FEC0:: will hold for whatever new space gets defined. The counter-argument to this stems from the fact that: 1) completely disconnected networks are relatively rare, and 2) whichever address space you use, you have to renumber *completely* anyway, so it doesn't matter that much which one it is. (On the other hand, if you can avoid renumbering by NAT, it is very important you don't clash with any existing global address space.) For my disconnected networks (small ones, admittably), I've certainly never bothered with FEC0::/10. That was the observation from some other operators as well. As for hijacking -- that's a problem when you become non-disconnected. A bug wherever you're connected to. (FWIW, I'm ok with a semi-standard address space, which is treated as globals. For example, the documentation prefix will probably be used to some extent.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 26 11:18:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJIIVV014767; Wed, 26 Mar 2003 11:18:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJIICO014766; Wed, 26 Mar 2003 11:18:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJIEVV014750 for ; Wed, 26 Mar 2003 11:18:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJIMcU011925 for ; Wed, 26 Mar 2003 11:18:22 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22357 for ; Wed, 26 Mar 2003 12:18:16 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:18:16 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:18:16 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:18:16 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:18:16 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Mar 2003 11:18:15 -0800 Content-class: urn:content-classes:message Message-Id: <963621801C6D3E4A9CF454A1972AE8F50455E9@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLzzBnR676lyVJyQuCqQWMo0CHghwAABNVA From: "Michel Py" To: "David Conrad" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QJIEVV014751 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > David Conrad wrote: > - Estimated world population as of 3/26/03, 17:40:10 GMT+5: People interested in IPv6 addresses related to population can have a look at the following link. http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Michel. -------------------------------------------------------------------- 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 Mar 26 11:22:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJMQVV014955; Wed, 26 Mar 2003 11:22:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJMQV1014954; Wed, 26 Mar 2003 11:22:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJMMVV014946 for ; Wed, 26 Mar 2003 11:22:22 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJMVHP028807 for ; Wed, 26 Mar 2003 11:22:31 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21657 for ; Wed, 26 Mar 2003 11:22:25 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:22:22 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:22:22 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:22:22 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:22:21 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Mar 2003 11:22:21 -0800 Content-class: urn:content-classes:message Message-Id: <963621801C6D3E4A9CF454A1972AE8F50455EA@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLzzBnR676lyVJyQuCqQWMo0CHghwAAMUsg From: "Michel Py" To: "David Conrad" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QJMMVV014947 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > David Conrad wrote: > One of the downsides of site locals is the same downside > you get with 1918 space -- merge two companies using private > address space and you'll probably have to deal with address > space collisions, forcing one of the two to renumber. There at least two drafts to make site-local addresses unique. Michel. -------------------------------------------------------------------- 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 Mar 26 11:24:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJObVV015062; Wed, 26 Mar 2003 11:24:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJObG8015061; Wed, 26 Mar 2003 11:24:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJOYVV015054 for ; Wed, 26 Mar 2003 11:24:34 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJOgcU014578 for ; Wed, 26 Mar 2003 11:24:43 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23316 for ; Wed, 26 Mar 2003 11:24:37 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:24:37 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:24:36 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:24:36 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:24:36 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Mar 2003 11:24:35 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLzyzdRD5sSekkcTOa43tIciX7XZAAAIW9w From: "Michel Py" To: "Tony Hain" , "Pekka Savola" Cc: , "Bob Hinden" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QJOYVV015055 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Pekka Savola wrote: >> People didn't see the need for RFC1918 space in IPv6. Because of site-locals. With site-locals gone it is an entirely new ballgame. There is a need for private addresses, people will use them no matter if they are site-locals, 6to4 addresses with a v4 RFC1918 address or plain hijack of a global prefix like in the good old days. Then someone will write an RFC to try to contain the hijacks into a well-known range. I have a sense of déjà vu. > Tony Hain wrote: > Just like they didn't see the need for private address space > in IPv4 until there were massive deployments of whatever > random numbers people found in documents. For those who have > forgotten, private address space was not set aside to support > NAT, it exists to provide space for disconnected networks, > that won't collide with existing allocations when those attach. > NAT came along later and took advantage of the existence of > private space. > There is a need for address space for disconnected networks. > If the argument is to set aside a different set of address > space and define it as unroutable, what is the point? We > already have a defined unroutable space, what value does a > different one add? Any issues that are raised for FEC0:: will > hold for whatever new space gets defined. Agree. Michel. -------------------------------------------------------------------- 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 Mar 26 11:39:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJdkVV015496; Wed, 26 Mar 2003 11:39:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJdjO0015494; Wed, 26 Mar 2003 11:39:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJdgVV015486 for ; Wed, 26 Mar 2003 11:39:42 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJdpcU020418 for ; Wed, 26 Mar 2003 11:39:51 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05117 for ; Wed, 26 Mar 2003 11:39:46 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:39:45 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:39:45 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:39:45 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:39:44 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2QJdcI07378; Wed, 26 Mar 2003 21:39:38 +0200 Date: Wed, 26 Mar 2003 21:39:37 +0200 (EET) From: Pekka Savola To: Michel Py cc: Tony Hain , , Bob Hinden Subject: RE: A use for site local addresses? In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Mar 2003, Michel Py wrote: > >> Pekka Savola wrote: > >> People didn't see the need for RFC1918 space in IPv6. > > Because of site-locals. With site-locals gone it is an entirely new > ballgame. There is a need for private addresses, people will use them no > matter if they are site-locals, 6to4 addresses with a v4 RFC1918 address > or plain hijack of a global prefix like in the good old days. Then > someone will write an RFC to try to contain the hijacks into a > well-known range. I have a sense of déjà vu. Right .. but this was covered in the meeting. Those folks present felt that there really is little need for "RFC1918-like" space even if site-locals get deprecated. I think this was quite explicit. As for the alternatives, you already listed some, plus using site-locals regardless of the deprecation. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 26 11:39:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJdqVV015507; Wed, 26 Mar 2003 11:39:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJdpb5015506; Wed, 26 Mar 2003 11:39:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJdjVV015493 for ; Wed, 26 Mar 2003 11:39:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJdscU020436 for ; Wed, 26 Mar 2003 11:39:54 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05146 for ; Wed, 26 Mar 2003 11:39:48 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:39:48 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:36:53 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:39:47 Z Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:39:47 Z Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QJdZ9a001174; Wed, 26 Mar 2003 11:39:35 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACQ54514; Wed, 26 Mar 2003 11:39:33 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA15065; Wed, 26 Mar 2003 11:39:33 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-Id: <16002.501.554704.788394@thomasm-u1.cisco.com> Date: Wed, 26 Mar 2003 11:39:33 -0800 (PST) To: "Michel Py" Cc: "Tony Hain" , "Pekka Savola" , , "Bob Hinden" Subject: RE: A use for site local addresses? In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QJdkVV015495 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py writes: > >> Pekka Savola wrote: > >> People didn't see the need for RFC1918 space in IPv6. > > Because of site-locals. With site-locals gone it is an entirely new ballgame. There is a need for private addresses, people will use them no matter if they are site-locals, 6to4 addresses with a v4 RFC1918 address or plain hijack of a global prefix like in the good old days. Then someone will write an RFC to try to contain the hijacks into a well-known range. I have a sense of déjà vu. There is some appeal to 6to4 and 1918... it keeps the problem within the cesspool of current usage and doesn't try to rationalize it any further. A maze of twisty addresses, all alike... Mike -------------------------------------------------------------------- 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 Mar 26 11:57:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJvqVV016128; Wed, 26 Mar 2003 11:57:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QJvqaH016127; Wed, 26 Mar 2003 11:57:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QJvmVV016120 for ; Wed, 26 Mar 2003 11:57:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QJvvcU027274 for ; Wed, 26 Mar 2003 11:57:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21920 for ; Wed, 26 Mar 2003 12:57:51 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:57:39 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:57:15 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:57:15 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 19:57:15 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Mar 2003 11:57:15 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D23@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLzz3GEGkX68nl/Sk6vG7n5A1yH0wAAPI2g From: "Michel Py" To: "Pekka Savola" Cc: "Tony Hain" , , "Bob Hinden" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QJvnVV016121 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > As for the alternatives, you already listed some, plus using > site-locals regardless of the deprecation. Right, and also keeping one's 3FFE:: address even after they are recalled on 6/6/6. Michel. -------------------------------------------------------------------- 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 Mar 26 12:03:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QK3FVV016225; Wed, 26 Mar 2003 12:03:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QK3F3M016224; Wed, 26 Mar 2003 12:03:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QK3BVV016214 for ; Wed, 26 Mar 2003 12:03:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QK3KcU029551 for ; Wed, 26 Mar 2003 12:03:20 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20934 for ; Wed, 26 Mar 2003 13:03:09 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:02:29 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:02:26 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:02:26 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:02:26 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA28964 for ; Wed, 26 Mar 2003 20:02:24 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA15245 for ; Wed, 26 Mar 2003 20:02:24 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2QK2Oi09054 for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:02:24 GMT Date: Wed, 26 Mar 2003 20:02:24 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030326200224.GC7415@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> <16002.501.554704.788394@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16002.501.554704.788394@thomasm-u1.cisco.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Mar 26, 2003 at 11:39:33AM -0800, Michael Thomas wrote: > There is some appeal to 6to4 and 1918... it keeps > the problem within the cesspool of current usage > and doesn't try to rationalize it any further. > A maze of twisty addresses, all alike... But as Pekka says, won't 6to4 interfaces fail to deliver to 2002: if the network is IPv6 only, or doesn't use IPv4 private IPs? 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 Wed Mar 26 12:26:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKQ6VV016771; Wed, 26 Mar 2003 12:26:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QKQ6Sv016770; Wed, 26 Mar 2003 12:26:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKQ3VV016763 for ; Wed, 26 Mar 2003 12:26:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QKQCcU009090 for ; Wed, 26 Mar 2003 12:26:12 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06868 for ; Wed, 26 Mar 2003 12:26:06 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:26:06 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:26:03 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:26:03 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:26:02 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2QKN6C07405; Wed, 26 Mar 2003 21:23:10 +0100 Message-Id: <3E820C2A.5060207@it.su.se> Date: Wed, 26 Mar 2003 21:23:06 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com, "'Bob Hinden & Margaret Wasserman'" Subject: Re: A use for site local addresses? References: <047c01c2f3bf$1dbc7bb0$ee1a4104@eagleswings> In-Reply-To: <047c01c2f3bf$1dbc7bb0$ee1a4104@eagleswings> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: >list, because this is not a trival issue. From reports I heard the whole >SF discussion was based on a bogus assertion that SL == NAT. > > > Not true. In fact non-global addresses are just as bad as NAT from an applications point of view but the discussion is SF was _not_ based on a missunderstanding of what sl is or isn't. At least not on my part. Cheers Leif -------------------------------------------------------------------- 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 Mar 26 12:31:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKV1VV016872; Wed, 26 Mar 2003 12:31:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QKV10L016871; Wed, 26 Mar 2003 12:31:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKUtVV016861 for ; Wed, 26 Mar 2003 12:30:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QKV4cU014793 for ; Wed, 26 Mar 2003 12:31:04 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05456 for ; Wed, 26 Mar 2003 13:30:59 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:30:58 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:28:03 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:30:58 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:30:57 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2QKUPEO045340; Wed, 26 Mar 2003 21:30:25 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QKUN1F251276; Wed, 26 Mar 2003 21:30:24 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29060 from ; Wed, 26 Mar 2003 21:30:18 +0100 Message-Id: <3E820D95.733CBDE0@hursley.ibm.com> Date: Wed, 26 Mar 2003 21:29:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Tim Chown Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> <16002.501.554704.788394@thomasm-u1.cisco.com> <20030326200224.GC7415@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > > On Wed, Mar 26, 2003 at 11:39:33AM -0800, Michael Thomas wrote: > > There is some appeal to 6to4 and 1918... it keeps > > the problem within the cesspool of current usage > > and doesn't try to rationalize it any further. > > A maze of twisty addresses, all alike... > > But as Pekka says, won't 6to4 interfaces fail to deliver to 2002: > if the network is IPv6 only, or doesn't use IPv4 private IPs? They will fail. Delivery to private addresses does fail. That's because they're private. The point of mentioning 6to4 is that if you own one lousy IPv4 address, that gives you a /48. No need to use RFC 1918 addresses for that. Brian -------------------------------------------------------------------- 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 Mar 26 12:31:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKVJVV016882; Wed, 26 Mar 2003 12:31:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QKVJdn016881; Wed, 26 Mar 2003 12:31:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKVDVV016874 for ; Wed, 26 Mar 2003 12:31:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QKVLHP024487 for ; Wed, 26 Mar 2003 12:31:21 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03934 for ; Wed, 26 Mar 2003 13:31:15 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:31:14 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:31:14 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:31:14 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:31:14 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 26 Mar 2003 12:31:13 -0800 Content-class: urn:content-classes:message Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D24@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLz1CFFj0F2YUlpTreyfzJM7GH8/AAAAnvA From: "Michel Py" To: "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QKVDVV016875 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michael Thomas wrote: >> There is some appeal to 6to4 and 1918... it keeps >> the problem within the cesspool of current usage >> and doesn't try to rationalize it any further. >> A maze of twisty addresses, all alike... > Tim Chown wrote: > But as Pekka says, won't 6to4 interfaces fail to > deliver to 2002: if the network is IPv6 only, > or doesn't use IPv4 private IPs? I don't see why. 6to4 addresses are supposed to be completely routable within a site until they reach the 6to4 gateway typically placed at the edge. With that one IPv4 address which is the gateway, you get a /48 6to4 prefix which does indeed includes 16 bits for local subnet topology. Looking at my own network, if I wanted to use 6to4 as the internal private scheme, I just have to delete the following on the edge router: | interface Tunnel6 | description for ipv6 6to4 tunnels | ipv6 address 2002:D1E9:7E41::1/64 | ipv6 traffic-filter IPV6-ACL-OUTSIDE-IN in | tunnel source Ethernet0/0 | tunnel mode ipv6ip 6to4 | tunnel path-mtu-discovery and also delete | ipv6 route 2002::/16 Tunnel6 And the 2002: internal routing still works with whatever IGP I choose (I have not tried with IS-IS). Voilà. On the host side, make sure that they pick the RA announcing the 6to4 prefix. Besides, if one does not need a prefix as short as a /24, here's another good candidate for hijacking: 2001:0DB8::/32. I guess it makes the documentation easy to write :-) Michel. -------------------------------------------------------------------- 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 Mar 26 12:38:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKc4VV017396; Wed, 26 Mar 2003 12:38:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QKc36I017395; Wed, 26 Mar 2003 12:38:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKc0VV017388 for ; Wed, 26 Mar 2003 12:38:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QKc9HP027033 for ; Wed, 26 Mar 2003 12:38:09 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21979 for ; Wed, 26 Mar 2003 13:38:03 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:21:34 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:21:33 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:21:33 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:21:32 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 1BD82816967; Wed, 26 Mar 2003 12:21:32 -0800 (PST) To: Keith Moore Cc: alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from Keith Moore dated Wed, 26 Mar 2003 09:33:52 EST Date: Wed, 26 Mar 2003 12:21:32 -0800 From: Naiming Shen Message-Id: <20030326202132.1BD82816967@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ] > As long as we are clear that, the "site-local" does not get special ] > treatment in terms of routing and dns, we should care less about if ] > "site-local" is deprecated or still lived. ] ] no. this is not sufficient. apps must not need to care about ] site-local either. If an application choose to care about SL and non-SL, I have no problem at all. It's not our business to discuss it here. ] nor is it acceptable to treat site-local as a ] security mechanism. If they trust the SL as their security mechanism(like 99% of IPv4 users do it today), its their problem not to use firewall, but it should not be forbidden. ] ] > It's perfectly fine and ] > actually somewhat useful if "site-local" plays the same role as in ] > IPv4 addresses defined in rfc1918. ] ] no. rfc1918 has been a disaster. we need to learn from past mistakes, ] not repeat them. If any IP users think using rfc1918 is a disaster, again, it's their choice to avoid them(if they can get globally routable addresses). there are many reasons to use rfc1918 addresses, not all related to the internet security. ] ] -------------------------------------------------------------------- ] 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 ] -------------------------------------------------------------------- - Naiming -------------------------------------------------------------------- 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 Mar 26 12:52:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKqbVV017821; Wed, 26 Mar 2003 12:52:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QKqb2U017820; Wed, 26 Mar 2003 12:52:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKqXVV017813 for ; Wed, 26 Mar 2003 12:52:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QKqgHP001859 for ; Wed, 26 Mar 2003 12:52:42 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02302 for ; Wed, 26 Mar 2003 13:52:36 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:52:36 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:49:41 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:52:36 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:52:35 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2QKq0j08209; Wed, 26 Mar 2003 22:52:00 +0200 Date: Wed, 26 Mar 2003 22:51:59 +0200 (EET) From: Pekka Savola To: Michel Py cc: Tim Chown , Subject: RE: A use for site local addresses? In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D24@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Mar 2003, Michel Py wrote: > >> Michael Thomas wrote: > >> There is some appeal to 6to4 and 1918... it keeps > >> the problem within the cesspool of current usage > >> and doesn't try to rationalize it any further. > >> A maze of twisty addresses, all alike... > > > Tim Chown wrote: > > But as Pekka says, won't 6to4 interfaces fail to > > deliver to 2002: if the network is IPv6 only, > > or doesn't use IPv4 private IPs? > > I don't see why. 6to4 addresses are supposed to be completely routable > within a site until they reach the 6to4 gateway typically placed at the > edge. With that one IPv4 address which is the gateway, you get a /48 > 6to4 prefix which does indeed includes 16 bits for local subnet > topology. Looking at my own network, if I wanted to use 6to4 as the > internal private scheme, I just have to delete the following on the edge > router: > > | interface Tunnel6 > | description for ipv6 6to4 tunnels > | ipv6 address 2002:D1E9:7E41::1/64 > | ipv6 traffic-filter IPV6-ACL-OUTSIDE-IN in > | tunnel source Ethernet0/0 > | tunnel mode ipv6ip 6to4 > | tunnel path-mtu-discovery > > and also delete > > | ipv6 route 2002::/16 Tunnel6 > > And the 2002: internal routing still works with whatever IGP I choose (I > have not tried with IS-IS). Voilà. On the host side, make sure that they > pick the RA announcing the 6to4 prefix. The point you're missing is that RFC3056 requires/recommends the 6to4 pseudo-interface implementations to discard packets received-from/would-be-sent-to 2002:FOO, where FOO is private. This is not a problem *unless* some node in your network is configured with a 6to4 pseudo-interface -- and I believe many of them are (e.g. Windows boxes, etc.). Different kind of trouble would occur if you didn't use private addresses and didn't have edge router corresponding to FOO enabling the 6to4 pseudo-interface. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 26 12:55:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKtwVV017914; Wed, 26 Mar 2003 12:55:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QKtw8l017913; Wed, 26 Mar 2003 12:55:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QKtsVV017905 for ; Wed, 26 Mar 2003 12:55:54 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QKu3cU022936 for ; Wed, 26 Mar 2003 12:56:03 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02720 for ; Wed, 26 Mar 2003 12:55:57 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:55:46 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:52:51 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:55:46 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 20:55:45 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 271B58FAF; Wed, 26 Mar 2003 21:55:42 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 3136E8F67; Wed, 26 Mar 2003 21:55:36 +0100 (CET) From: "Jeroen Massar" To: "'Naiming Shen'" Cc: Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 21:56:40 +0100 Organization: Unfix Message-Id: <010401c2f3da$33950720$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030326202132.1BD82816967@prattle.redback.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QKtsVV017906 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Naiming Shen wrote: > If any IP users think using rfc1918 is a disaster, again, it's their > choice to avoid them(if they can get globally routable addresses). If one chooses to ignore any standards it's their problem. Which indeed is true. > there are many reasons to use rfc1918 addresses, not all related to > the internet security. Name and eloborate on them. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 13:32:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QLW3VV018423; Wed, 26 Mar 2003 13:32:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QLW2Rh018422; Wed, 26 Mar 2003 13:32:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QLVxVV018415 for ; Wed, 26 Mar 2003 13:31:59 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QLW8cU005985 for ; Wed, 26 Mar 2003 13:32:08 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28932 for ; Wed, 26 Mar 2003 13:32:02 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 21:31:58 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 21:31:56 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 21:31:55 Z Received: from mail.libertysurf.net (mail.libertysurf.net [213.36.80.91]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 21:31:55 Z Received: from enst.fr (212.83.172.148) by mail.libertysurf.net (6.5.026) id 3E7C21CF000CB96B for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:31:54 +0100 Message-Id: <3E821C77.4050203@enst.fr> Date: Wed, 26 Mar 2003 22:32:39 +0100 From: Mohamed KOUBAA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Disubscribe Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Disubscribe -------------------------------------------------------------------- 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 Mar 26 14:19:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QMJ2VV018762; Wed, 26 Mar 2003 14:19:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QMJ21B018761; Wed, 26 Mar 2003 14:19:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QMIwVV018754 for ; Wed, 26 Mar 2003 14:18:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QMJ7HP004437 for ; Wed, 26 Mar 2003 14:19:07 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22756 for ; Wed, 26 Mar 2003 15:19:02 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:19:01 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:16:06 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:19:01 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:19:01 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Mar 2003 14:19:00 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F50455EE@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLz2Y3hSYUC91eQS3e2YPBhuQvnvwAAEbFQ From: "Michel Py" To: "Pekka Savola" Cc: "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QMIxVV018755 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > The point you're missing is that RFC3056 requires/recommends > the 6to4 pseudo-interface implementations to discard packets > received-from/would-be-sent-to 2002:FOO, where FOO is private. > This is not a problem *unless* some node in your network is > configured with a 6to4 pseudo-interface -- and I believe many > of them are (e.g. Windows boxes, etc.). That's precisely my point: this is a feature, not a bug. A host MUST NOT use a private address to talk to the outside of its site. Very close to the top of the list of what needs to be done to insure this is to remove all 6to4 pseudo-interfaces. Therefore, using 2002:: as a real 6to4 site and not with individual hosts using their own IPv4 address as the 6to4 address does actually enforce the removal of 6to4 pseudo-interfaces because if they exist it won't work at all (if the implementation enforces RFC3056). Michel. -------------------------------------------------------------------- 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 Mar 26 14:39:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QMdhVV018991; Wed, 26 Mar 2003 14:39:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QMdhAb018990; Wed, 26 Mar 2003 14:39:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QMdeVV018983 for ; Wed, 26 Mar 2003 14:39:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QMdncU002637 for ; Wed, 26 Mar 2003 14:39:49 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29478 for ; Wed, 26 Mar 2003 15:39:27 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:38:19 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:38:19 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:38:18 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 22:38:18 Z Received: from IDLEWYLDE.windriver.com ([147.11.46.223]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA05715; Wed, 26 Mar 2003 14:37:55 -0800 (PST) Message-Id: <5.1.0.14.2.20030326173256.04076a28@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Mar 2003 17:35:39 -0500 To: "EricLKlein" From: Margaret Wasserman Subject: Re: A use for site local addresses? Cc: In-Reply-To: <00d201c2f2ad$e24ee340$67061eac@ttitelecom.com> References: <751C3918-5EA0-11D7-B5E2-000393AB1404@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Eric, > > Site-locals was voted down in the WG meeting in SF. >How do those of us who can not attend these conferences get into these >limited participation votes? I for one can not make frequent international >trips for a non-customer related meeting. Two points of clarification: (1) We did not "vote down" site-locals. The chairs asked for a show of hands on the issue, to allow us to determine if there was WG consensus to deprecate site-locals. In the case, the chairs (Bob Hinden and I) did believe that consensus was reached within the room to deprecate site-locals. (2) Like all consensus points that are reached in meetings, this issue will be checked on the mailing list. Bob and I will send a formal consensus check to the list shortly. Margaret -------------------------------------------------------------------- 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 Mar 26 15:02:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QN2vVV019232; Wed, 26 Mar 2003 15:02:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QN2v63019231; Wed, 26 Mar 2003 15:02:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QN2sVV019224 for ; Wed, 26 Mar 2003 15:02:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QN32cU010719 for ; Wed, 26 Mar 2003 15:03:02 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13966 for ; Wed, 26 Mar 2003 16:02:56 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:02:56 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:02:55 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:02:55 Z Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:02:54 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2QN2q33110846 for ; Thu, 27 Mar 2003 00:02:52 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2QN2qMr291072 for ; Thu, 27 Mar 2003 00:02:52 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25138 from ; Thu, 27 Mar 2003 00:02:50 +0100 Message-Id: <3E823158.C370E0A4@hursley.ibm.com> Date: Thu, 27 Mar 2003 00:01:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <963621801C6D3E4A9CF454A1972AE8F50455EE@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > > > Pekka Savola wrote: > > The point you're missing is that RFC3056 requires/recommends > > the 6to4 pseudo-interface implementations to discard packets > > received-from/would-be-sent-to 2002:FOO, where FOO is private. > > This is not a problem *unless* some node in your network is > > configured with a 6to4 pseudo-interface -- and I believe many > > of them are (e.g. Windows boxes, etc.). > > That's precisely my point: this is a feature, not a bug. A host MUST NOT > use a private address to talk to the outside of its site. Very close to > the top of the list of what needs to be done to insure this is to remove > all 6to4 pseudo-interfaces. Therefore, using 2002:: as a real > 6to4 site and not with individual hosts using their own IPv4 address as > the 6to4 address does actually enforce the removal of 6to4 > pseudo-interfaces because if they exist it won't work at all (if the > implementation enforces RFC3056). That's correct as long as the RFC3056 code is only enabled in the site border router. If it's enabled in any internal routers, the packets will get black holed internally. Also if you have any hosts that support 6to4, which is not the model described in RFC3056 but is shipped in at least one o/s, strange things may happen. Brian -------------------------------------------------------------------- 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 Mar 26 15:39:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QNdZVV019709; Wed, 26 Mar 2003 15:39:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2QNdZdW019708; Wed, 26 Mar 2003 15:39:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2QNdVVV019701 for ; Wed, 26 Mar 2003 15:39:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2QNdecU024144 for ; Wed, 26 Mar 2003 15:39:41 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28032 for ; Wed, 26 Mar 2003 15:39:35 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:39:35 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:36:40 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:39:34 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Wed, 26 Mar 2003 23:39:34 Z Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Mar 2003 15:39:34 -0800 Content-class: urn:content-classes:message Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D28@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcLz7cnzPwkoQbmoSKKaZGlYpFIS6QAABO0g From: "Michel Py" To: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2QNdWVV019702 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian E Carpenter > That's correct as long as the RFC3056 code is only enabled in > the site border router. If it's enabled in any internal routers, > the packets will get black holed internally. I don't think so. They will be blackholed only if the traffic crosses a 6to4 tunnel interface, not if the 6to4 address is treated/configured as a regular IPv6 address. If the routing table contains IGP or connected routes with a mask of /64 as it should be the longest match route will prevail over the 2002::/16 route associated with the tunnel interface and traffic should flow. If there is no match in the routing table then traffic will indeed be blackholed and that's a feature not a bug. Michel. -------------------------------------------------------------------- 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 Mar 26 16:09:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R08xVV019951; Wed, 26 Mar 2003 16:08:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R08xC3019950; Wed, 26 Mar 2003 16:08:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R08uVV019943 for ; Wed, 26 Mar 2003 16:08:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R095HP013752 for ; Wed, 26 Mar 2003 16:09:05 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04636 for ; Wed, 26 Mar 2003 17:08:59 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:08:59 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:08:59 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:08:58 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:08:57 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 2FFCA868F2B; Wed, 26 Mar 2003 16:08:56 -0800 (PST) To: "Jeroen Massar" Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from "Jeroen Massar" dated Wed, 26 Mar 2003 21:56:40 +0100 <010401c2f3da$33950720$210d640a@unfix.org> Date: Wed, 26 Mar 2003 16:08:56 -0800 From: Naiming Shen Message-Id: <20030327000856.2FFCA868F2B@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ] Naiming Shen wrote: ] ] ] ] > If any IP users think using rfc1918 is a disaster, again, it's their ] > choice to avoid them(if they can get globally routable addresses). ] ] If one chooses to ignore any standards it's their problem. ] Which indeed is true. ] ] > there are many reasons to use rfc1918 addresses, not all related to ] > the internet security. ] ] Name and eloborate on them. some examples which are not security specific: - to use the same gateway address in multiple locations for devices like laptops, assume someone does not want to run dhcp overhead. - someone does not want the addresses to be global dns reachable. some ISPs assign private addresses on all their backbone links just for that. the names showing up when they do internal troubleshooting, but not in external domain traceroute. - in router/etc documentation, its nice to have diagrams showing routers having 10.x.x.x addresses in their configuration examples, its not good to put legal addresses over there. - of course in v4, addresses are not free. - its safer to use private addresses during testing, e.g. routing protocol testing in lab. even if you leak out those addresses by mistake, the chances are your peer, or upstream is filtering them, so the damage is minimized. i think my point on this related to SL is that, the SL space is already carved and well known already to everyone, what is the point to reclaim it for "normal" use? though i'm absolutely against to have routing/dns support to SL. cheers. ] ] Greets, ] Jeroen ] ] ] -------------------------------------------------------------------- ] 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 ] -------------------------------------------------------------------- - Naiming -------------------------------------------------------------------- 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 Mar 26 16:25:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R0PFVV020220; Wed, 26 Mar 2003 16:25:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R0PFLn020219; Wed, 26 Mar 2003 16:25:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R0PCVV020212 for ; Wed, 26 Mar 2003 16:25:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R0PLcU009827 for ; Wed, 26 Mar 2003 16:25:21 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16335 for ; Wed, 26 Mar 2003 17:25:15 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:24:46 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:24:23 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:24:23 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 00:24:22 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5A712897B; Thu, 27 Mar 2003 01:24:20 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 773458574; Thu, 27 Mar 2003 01:24:08 +0100 (CET) From: "Jeroen Massar" To: "'Naiming Shen'" Cc: Subject: RE: A use for site local addresses? Date: Thu, 27 Mar 2003 01:25:11 +0100 Organization: Unfix Message-Id: <015a01c2f3f7$55835fe0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030327000856.2FFCA868F2B@prattle.redback.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2R0PCVV020213 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Naiming Shen [mailto:naiming@redback.com] wrote: > ] Naiming Shen wrote: > ] > ] > ] > ] > If any IP users think using rfc1918 is a disaster, > again, it's their > ] > choice to avoid them(if they can get globally routable > addresses). > ] > ] If one chooses to ignore any standards it's their problem. > ] Which indeed is true. > ] > ] > there are many reasons to use rfc1918 addresses, not all > related to > ] > the internet security. > ] > ] Name and eloborate on them. > > some examples which are not security specific: > > - to use the same gateway address in multiple locations for devices > like laptops, assume someone does not want to run dhcp overhead. IPv6 also has RA, I don't see a point here. Also if you are talking gateways then you are also quite possibly talking about internet connected devices, thus you will need to be globally unique. > - someone does not want the addresses to be global dns > reachable. some ISPs assign private addresses on all > their backbone links just for that. > the names showing up when they do internal troubleshooting, > but not in external domain traceroute. Use a /48 out of the ISP's /32 and use that for those backbone links. Then even people who are outside of the network still can find out that this address space is owned by that ISP. As for names showing up, those can only be handy to identify them. Otherwise either use seperate DNS's or use BIND's 'view' capability. Ofcourse other DNS implementations might have other facilities. > - in router/etc documentation, its nice to have diagrams > showing routers having 10.x.x.x addresses in their > configuration examples, its not good to put legal > addresses over there. That's where 2001:db8::/32 is for. > - of course in v4, addresses are not free. In IPv6 they won't be free either. If you want 'free' space just pick some random addresses and use them. But then don't complain that you can't route it over the internet etc. > - its safer to use private addresses during testing, e.g. routing > protocol testing in lab. even if you leak out those addresses by > mistake, the chances are your peer, or upstream is filtering them, > so the damage is minimized. Then don't route it to the outside. Use firewalls etc. One could also 'forget' to filter 2001:db8::/32 or any other space. How many IPv4 smurfamp gateways where there still on the internet? and how many ISP's do actually filter on egress from their customers? > i think my point on this related to SL is that, the SL space > is already carved and well known already to everyone, what is > the point to reclaim it for "normal" use? though i'm absolutely > against to have routing/dns support to SL. I don't see any relation whatsoever to the above points. Also IPv6 is currently still not heavily deployed and still be carved so that problems related to SL will be gone. Also if you don't need routing then use fe80::/10. And what do you mean for not having SL support in DNS? How are you going to let an application get to that host then? Are you letting the user remember and type in a 128bits address? And what about security specific reasons? Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 17:11:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1BoVV020607; Wed, 26 Mar 2003 17:11:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R1BoUo020606; Wed, 26 Mar 2003 17:11:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1BkVV020599 for ; Wed, 26 Mar 2003 17:11:47 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R1BtHP005101 for ; Wed, 26 Mar 2003 17:11:55 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28735 for ; Wed, 26 Mar 2003 17:11:50 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:11:49 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:11:49 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:11:48 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:11:48 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id BAA01214 for ; Thu, 27 Mar 2003 01:11:46 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id BAA21757 for ; Thu, 27 Mar 2003 01:11:46 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2R1Bkc02817 for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:11:46 GMT Date: Thu, 27 Mar 2003 01:11:46 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030327011146.GF1347@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <963621801C6D3E4A9CF454A1972AE8F50455EE@server2000.arneill-py.sacramento.ca.us> <3E823158.C370E0A4@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E823158.C370E0A4@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Mar 27, 2003 at 12:01:44AM +0100, Brian E Carpenter wrote: > > Also if you have any hosts that support 6to4, which is not the model > described in RFC3056 but is shipped in at least one o/s, strange things > may happen. Indeed. But my (perhaps not well written) comment was based on Mike's requirement to have a multi-site community network, e.g. a number of DSL or dialup homes (who should by current RIR guidelines receive site /48's from their upstream providers) who also participate in a routed mesh WLAN network across a city (i.e. homes with 802.11b). The WLAN infrastructure needs its own address space, but site locals are desirable for the home networks connected via WLAN in the event that any home is disconnected. Also, transmission across the WLAN is likely to give better performance than routing out and back in through the DSL or dialup. If such homes get /48's, then the community mesh network needs more than a /48, which discounts 6to4 as a "site" solution, esp. if the infrastructure were v6-only (which to be fair is not yet a likely reality). In such a case there is no single upstream provider (the homes may subscribe to any service provider). Of course some community networks may only have one (fatter) upstream. But the more interesting ones allow you to select from multiple providers (e.g. open.net in Sweden) where you use site-locals to access community content until you authenticate to an external provider, at which point you receive global address(es). The current answer seems to be: a) Pick someone else's global /32 and use that b) Pick some other random /32 prefix c) Pay $$$ to get LIR status to get a global /32 d) Request as many GUSL-based /48's as are needed e) Use geo-addresses f) Use fec0 space anyway Option c) is out as it costs real $$$. Options d) and e) are not defined yet. So we might as well accept that people will use fec0, but simply not give that prefix any special scope treatment. Is it the scope rules that cause the problems, or the definition of an available prefix? As Michel says, we've been here with IPv4 before. At least with v6, market forces should lead people away from NAT (if they want the nice new v6 apps). I'm happy to see the back of site-locals, so long as current (and most importantly) future network requirements can be met without them, and at the same cost as site locals (free). 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 Wed Mar 26 17:12:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1CCVV020617; Wed, 26 Mar 2003 17:12:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R1CCXN020616; Wed, 26 Mar 2003 17:12:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1C6VV020609 for ; Wed, 26 Mar 2003 17:12:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R1CFHP005300 for ; Wed, 26 Mar 2003 17:12:15 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14215 for ; Wed, 26 Mar 2003 18:12:09 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:12:08 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:12:08 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:12:08 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:12:07 Z Received: from IDLEWYLDE.windriver.com ([147.11.46.223]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA15729; Wed, 26 Mar 2003 17:11:47 -0800 (PST) Message-Id: <5.1.0.14.2.20030326200850.035a2260@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 26 Mar 2003 20:09:51 -0500 To: From: Margaret Wasserman Subject: RE: A use for site local addresses? Cc: , "'Bob Hinden & Margaret Wasserman'" In-Reply-To: <047c01c2f3bf$1dbc7bb0$ee1a4104@eagleswings> References: <13E98A20-5F39-11D7-8225-000393DB5366@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >There are significantly more people on this list than you could fit in >one of the rooms in SF. The chairs need to raise the question on the >list, because this is not a trival issue. From reports I heard the whole >SF discussion was based on a bogus assertion that SL == NAT. The chairs WILL raise the question on the list... Please be patient. I took a couple of days off after the IETF and Bob hasn't been feeling well, but we'll get a question out to the list soon. Margaret -------------------------------------------------------------------- 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 Mar 26 17:24:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1OCVV021226; Wed, 26 Mar 2003 17:24:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R1OCiU021225; Wed, 26 Mar 2003 17:24:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1O7VV021207 for ; Wed, 26 Mar 2003 17:24:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R1OGHP009688 for ; Wed, 26 Mar 2003 17:24:16 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA00563 for ; Wed, 26 Mar 2003 18:24:11 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:24:10 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:21:14 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:24:09 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:24:09 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id D15ACA80044; Wed, 26 Mar 2003 17:24:08 -0800 (PST) To: "Jeroen Massar" Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from "Jeroen Massar" dated Thu, 27 Mar 2003 01:25:11 +0100 <015a01c2f3f7$55835fe0$210d640a@unfix.org> Date: Wed, 26 Mar 2003 17:24:08 -0800 From: Naiming Shen Message-Id: <20030327012408.D15ACA80044@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk my original comment was to "rfc1918 is a disaster", and your below reasoning is completely v6 related. i agree with you that all those problems can be solved with different mechansims(particularly in v6 domain), but they are not necessarily easier or better than using private addresses. more inline. ] Naiming Shen [mailto:naiming@redback.com] wrote: ] ] > ] Naiming Shen wrote: ] > ] ] > ] ] > ] ] > ] > If any IP users think using rfc1918 is a disaster, ] > again, it's their ] > ] > choice to avoid them(if they can get globally routable ] > addresses). ] > ] ] > ] If one chooses to ignore any standards it's their problem. ] > ] Which indeed is true. ] > ] ] > ] > there are many reasons to use rfc1918 addresses, not all ] > related to ] > ] > the internet security. ] > ] ] > ] Name and eloborate on them. ] > ] > some examples which are not security specific: ] > ] > - to use the same gateway address in multiple locations for devices ] > like laptops, assume someone does not want to run dhcp overhead. ] ] IPv6 also has RA, I don't see a point here. Also if you are ] talking gateways then you are also quite possibly talking ] about internet connected devices, thus you will need to be ] globally unique. ] ] > - someone does not want the addresses to be global dns ] > reachable. some ISPs assign private addresses on all ] > their backbone links just for that. ] > the names showing up when they do internal troubleshooting, ] > but not in external domain traceroute. ] ] Use a /48 out of the ISP's /32 and use that for those backbone links. ] Then even people who are outside of the network still can find out ] that this address space is owned by that ISP. ] ] As for names showing up, those can only be handy to identify them. ] Otherwise either use seperate DNS's or use BIND's 'view' capability. ] Ofcourse other DNS implementations might have other facilities. ] yes, you can do it those ways, but is that easier than using the private addresses? ] > - in router/etc documentation, its nice to have diagrams ] > showing routers having 10.x.x.x addresses in their ] > configuration examples, its not good to put legal ] > addresses over there. ] ] That's where 2001:db8::/32 is for. ] ] > - of course in v4, addresses are not free. ] ] In IPv6 they won't be free either. If you want 'free' space just ] pick some random addresses and use them. But then don't complain ] that you can't route it over the internet etc. again, is picking up random addresses better than using private addresses? isn't it creating more confusing for the users? ] ] > - its safer to use private addresses during testing, e.g. routing ] > protocol testing in lab. even if you leak out those addresses by ] > mistake, the chances are your peer, or upstream is filtering them, ] > so the damage is minimized. ] ] Then don't route it to the outside. Use firewalls etc. ] One could also 'forget' to filter 2001:db8::/32 or any other space. ] How many IPv4 smurfamp gateways where there still on the internet? ] and how many ISP's do actually filter on egress from their customers? i didn't mean packet filtering, rather route filtering with bgp. as far as the ISPs i know, they all filter private addresses from the routing level. it would be nuts to accept your peer's private address announcements. yes, people can 'forget' to do certain things, but it does not make it better to use random addresses. ] ] > i think my point on this related to SL is that, the SL space ] > is already carved and well known already to everyone, what is ] > the point to reclaim it for "normal" use? though i'm absolutely ] > against to have routing/dns support to SL. ] ] I don't see any relation whatsoever to the above points. ] Also IPv6 is currently still not heavily deployed and still ] be carved so that problems related to SL will be gone. ] ] Also if you don't need routing then use fe80::/10. ] And what do you mean for not having SL support in DNS? ] How are you going to let an application get to that host then? ] Are you letting the user remember and type in a 128bits address? what i meant is no "special" treatment in routing and dns for those addresses. of course they are still routable, otherwise it would be a "special" treatment. sure they can be put in your local dns record, but it can not be searched from the root domain servers. cheers. ] ] And what about security specific reasons? ] ] Greets, ] Jeroen ] ] ] -------------------------------------------------------------------- ] 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 ] -------------------------------------------------------------------- - Naiming -------------------------------------------------------------------- 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 Mar 26 17:48:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1mZVV022109; Wed, 26 Mar 2003 17:48:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R1mZZL022108; Wed, 26 Mar 2003 17:48:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1mWVV022101 for ; Wed, 26 Mar 2003 17:48:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R1mfcU008474 for ; Wed, 26 Mar 2003 17:48:41 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22015 for ; Wed, 26 Mar 2003 18:48:32 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:48:19 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:48:18 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:48:17 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:48:17 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 7C946897C; Thu, 27 Mar 2003 02:48:15 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id F1C4F7865; Thu, 27 Mar 2003 02:48:08 +0100 (CET) From: "Jeroen Massar" To: "'Naiming Shen'" Cc: Subject: RE: A use for site local addresses? Date: Thu, 27 Mar 2003 02:49:11 +0100 Organization: Unfix Message-Id: <016a01c2f403$113720e0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030327012408.D15ACA80044@prattle.redback.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2R1mWVV022102 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Naiming Shen [mailto:naiming@redback.com] wrote: > my original comment was to "rfc1918 is a disaster", and your below > reasoning is completely v6 related. i agree with you that all those > problems can be solved with different mechansims(particularly in v6 > domain), but they are not necessarily easier or better than using > private addresses. more inline. > ] > - someone does not want the addresses to be global dns > ] > reachable. some ISPs assign private addresses on all > ] > their backbone links just for that. > ] > the names showing up when they do internal troubleshooting, > ] > but not in external domain traceroute. > ] > ] Use a /48 out of the ISP's /32 and use that for those backbone links. > ] Then even people who are outside of the network still can find out > ] that this address space is owned by that ISP. > ] > ] As for names showing up, those can only be handy to identify them. > ] Otherwise either use seperate DNS's or use BIND's 'view' capability. > ] Ofcourse other DNS implementations might have other facilities. > ] > > yes, you can do it those ways, but is that easier than using the > private addresses? There is a difference between randomly picking a /48 from fec0:: or picking a globally unique /48 out of space you 'own'. And yes, dns requires configuration, but leaking private space into the global DNS isn't what one would like to see either. Example: A host with IPv4 10.0.0.1 and a public IPv6 address. Locally one can reach it over IPv4 and IPv6, but when trying to get to it over the public internet, where only the IPv6 address gets published there are no problems either, except that you can't reach it over IPv4 because it doesn't exist globally. Note that this is common practice today for sites having NATed IPv4 space but global connectivity using IPv6. If one did publish the RFC1918 IPv4 address in DNS one is bound to come across a local box one day, which might be a big surprise. Eg "telnet secure.example.net 'connected to secure' password" That is what uniquenes is all about. (yeah I know use SSH :) And ofcourse somebody could also route your unique prefix to an odd box if they really want to. Point in this part: never ever publish private addresses in the global DNS. > ] > - in router/etc documentation, its nice to have diagrams > ] > showing routers having 10.x.x.x addresses in their > ] > configuration examples, its not good to put legal > ] > addresses over there. > ] > ] That's where 2001:db8::/32 is for. > ] > ] > - of course in v4, addresses are not free. > ] > ] In IPv6 they won't be free either. If you want 'free' space just > ] pick some random addresses and use them. But then don't complain > ] that you can't route it over the internet etc. > > again, is picking up random addresses better than using private > addresses? isn't it creating more confusing for the users? Addresses are addresses and you do want them to be globally unique. Or are you expecting to never ever grow and by that merge networks with another, which might have the same space? > ] > - its safer to use private addresses during testing, > e.g. routing > ] > protocol testing in lab. even if you leak out those > addresses by > ] > mistake, the chances are your peer, or upstream is > filtering them, > ] > so the damage is minimized. > ] > ] Then don't route it to the outside. Use firewalls etc. > ] One could also 'forget' to filter 2001:db8::/32 or any other space. > ] How many IPv4 smurfamp gateways where there still on the internet? > ] and how many ISP's do actually filter on egress from their > customers? > > i didn't mean packet filtering, rather route filtering with bgp. > as far as the ISPs i know, they all filter private addresses from > the routing level. it would be nuts to accept your peer's private > address announcements. yes, people can 'forget' to do certain things, > but it does not make it better to use random addresses. I know a couple of badly behaved ISP's which simply do not filter because the CPU of make R and F would not be able to handle the load. Not everyone knows what RPF does unfortunatly. Spoofed (D)DOSses also show that quite well, because how could they spoof if the ISP filtered? Ever did a log of RFC1918 space coming into your network, not even talking about DNS's publishing RFC1918 space. > ] > i think my point on this related to SL is that, the SL space > ] > is already carved and well known already to everyone, what is > ] > the point to reclaim it for "normal" use? though i'm absolutely > ] > against to have routing/dns support to SL. > ] > ] I don't see any relation whatsoever to the above points. > ] Also IPv6 is currently still not heavily deployed and still > ] be carved so that problems related to SL will be gone. > ] > ] Also if you don't need routing then use fe80::/10. > ] And what do you mean for not having SL support in DNS? > ] How are you going to let an application get to that host then? > ] Are you letting the user remember and type in a 128bits address? > > what i meant is no "special" treatment in routing and dns for those > addresses. of course they are still routable, otherwise it would be > a "special" treatment. sure they can be put in your local dns record, > but it can not be searched from the root domain servers. With 'globaly routable' I mean that everyone on the internet would be able to reach them. All address space is routable ofcourse. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 26 17:58:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1w2VV022374; Wed, 26 Mar 2003 17:58:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R1w209022373; Wed, 26 Mar 2003 17:58:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R1vwVV022363 for ; Wed, 26 Mar 2003 17:57:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R1w7cU011193 for ; Wed, 26 Mar 2003 17:58:07 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21411 for ; Wed, 26 Mar 2003 18:58:01 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:58:01 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:58:01 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:58:01 Z Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 01:58:01 Z Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 26 Mar 2003 17:57:59 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 26 Mar 2003 17:57:59 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 26 Mar 2003 17:57:57 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 26 Mar 2003 17:57:56 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 26 Mar 2003 17:57:58 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Wed, 26 Mar 2003 17:57:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: A use for site local addresses? Date: Wed, 26 Mar 2003 17:57:52 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcL0ACliGvR8ufH7SuyY7fubTvcjgQAAyQew From: "Christian Huitema" To: X-OriginalArrivalTime: 27 Mar 2003 01:57:44.0611 (UTC) FILETIME=[421E1730:01C2F404] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2R1vxVV022364 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of the advocated uses of site local addresses was for disconnected sites. However, Dino made the point in the meeting that, if a site is truly disconnected, it can just as well pick any random addresses it wants. The absence of a "reserved range" (a la RFC 1918) will pressure the disconnected site to renumber when it actually connects, rather than go on using private addresses and a NAT. In fact, most large sites have at least one IPv4 address, and they can get a unique 2002::/48 prefix out of that address, even if they don't have an actual IPv6 ISP yet. -- Christian Huitema -------------------------------------------------------------------- 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 Mar 26 18:04:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R24kVV022808; Wed, 26 Mar 2003 18:04:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R24k2w022807; Wed, 26 Mar 2003 18:04:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R24gVV022800 for ; Wed, 26 Mar 2003 18:04:42 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R24pcU013472 for ; Wed, 26 Mar 2003 18:04:51 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28920 for ; Wed, 26 Mar 2003 18:04:46 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 02:04:45 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 02:04:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 02:04:44 Z Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 02:04:44 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DEB383639; Wed, 26 Mar 2003 21:04:43 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 26 Mar 2003 21:04:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Mobility in Nodes Requirements Date: Wed, 26 Mar 2003 21:04:43 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCE5D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mobility in Nodes Requirements Thread-Index: AcLzFDkbVurVLPzmSEeR4kKgt5wy2wA8GXYA From: "Bound, Jim" To: "Jari Arkko" Cc: "Kurt Erik Lindqvist" , X-OriginalArrivalTime: 27 Mar 2003 02:04:43.0686 (UTC) FILETIME=[3BE7DC60:01C2F405] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2R24hVV022801 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, This is all a moot point and discussion for me. Its informational. I will not support it in the industry as one individual (not speaking for my company). I will suggest it be used as guideline. That being said my point was missed and I don't see the point of fighting it for an Informational RFC that is questionable at best with its purpose. My point is there should be docs for 3gpp, Providers, Enterprises, et al. This is an attempt to appease different factions in the IETF that have an agenda in the market. I will not be part of it or support out of the IETF. Except as guideline that some good "technical" engineers like John, Jonne, et al took the time to work on and that part makes it possibly useful. I have no more to say on this issue. IF we meet in the market and debate be prepared to hear more, and I will be armed with what I would have used to appeal any IESG decision for proposed standard. This is plain wrong. But that is fine we all loose battles. But I will not give in and say it was right. How about NO. Regards, /jim >-----Original Message----- >From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] >Sent: Tuesday, March 25, 2003 4:19 PM >To: Bound, Jim >Cc: Kurt Erik Lindqvist; ipng@sunroof.eng.sun.com >Subject: Re: Mobility in Nodes Requirements > > > >(Sorry for not getting back to this issue sooner, but I just >got home after some touring at Tahoe and lengthy flights home.) > >> This is my exact point about this spec. >> >> It seems if this will continue without a focus as Kurtis says below >> and I have stated previously we will need a serious applicability >> statement. >> >> Because it is BCP I am backing off a little as most of the market >> don't care about our BCPs. But there needs to be applicability >> statement. > >Jim, > >Charter says Informational and I believe that is could be >acceptable to you as well? > >If by "without a focus" you mean that we are not describing >the requirements for IPv6-enabled servers flying in >helichopters, then I agree. That is, we do not describe what >IPv6 features should be used in specific applications. And >yes, there should be an applicability statement to this >effect. Perhaps you'd be willing to submit some text? > >However, I still feel strongly that we MUST describe what >"components" IPv6 has and what their mandatory/optional status >is. Not the need in a specific application, but whether >something is *always* needed. And a directory of optional >components. (In some specific subset of cases we can also give >a rule when the optional component becomes >mandatory.) > >I believe this is very useful for ensuring the >interoperability and success of IPv6, and I'm a bit surprised >that you seem to disagree. I've heard a number of counter >arguments to this kind of specifications and I would like to >take this opportunity to discuss them: > >* "Its obvious". Right. So why we are debating the > keywords for DHCP and MIPv6...? > >* "Its in the other RFCs already". Probably so, at least in > some cases. If you dig up the information by reading all > RFCs, that is. And I know for a fact that some specifications > explicitly left the decision out; at least MIPv6 does > this in expectation of IPv6 saying something about it its > specifications. > >* "We can't agree anyway what the mandatory components are". So, > we shift our problem to the customers and end-users? No, let > the buck stop here. Not in IESG, vendors, or customers. > >* "All this depends on the applications." Some things depend > on the applications. But not all. And even if some things > are needed on a per application basis, wouldn't it be useful > to document that so that no one mistakes something for > mandatory? > >* "Market place decides anyway." Yeah. But in my experience > the rules in IETF specifications still have a lot of > weight. > >* "The set of requirements for any specific application > is going to be much different or more extensive than > this". I agree. But no one claimed this was all you > had to do to protect the flying servers. > >* "Maybe you can list the mandatory components, but I don't > see a need to look at the optional ones." Well, how do I > know that if RFC nnnn isn't listed, its (a) optional or (b) > forgotten? I say we should be explicit and list the optional > components too. > >* "Early IPv4 RFCs were so bad that we needed a lot of explanations, > but it doesn't apply to IPv6 anymore". I agree, but if you look > at the node requirements document, it doesn't follow the IPv4 > host requirements style at all. We only list specific RFCs. > There's a small number of cases where large RFCs contain a number > of independent pieces (such as MIPv6) that we have also listed. > But I agree, we shouldn't be explaining and patching existing > RFCs. Fortunately, we are not doing that. > >Jari > > > -------------------------------------------------------------------- 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 Mar 26 19:06:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R36jVV023527; Wed, 26 Mar 2003 19:06:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R36j5I023526; Wed, 26 Mar 2003 19:06:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R36fVV023519 for ; Wed, 26 Mar 2003 19:06:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R36ocU003912 for ; Wed, 26 Mar 2003 19:06:50 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12732 for ; Wed, 26 Mar 2003 20:06:44 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:06:44 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:03:48 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:06:44 Z Received: from turkey.mail.pas.earthlink.net (turkey.mail.pas.earthlink.net [207.217.120.126]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:06:43 Z Received: from sdn-ap-028tnnashp0330.dialsprint.net ([209.199.137.76] helo=cs.utk.edu) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yNiu-0007Iu-00; Wed, 26 Mar 2003 19:06:36 -0800 Date: Wed, 26 Mar 2003 22:06:33 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com To: Naiming Shen From: Keith Moore In-Reply-To: <20030326202132.1BD82816967@prattle.redback.com> Message-Id: <1D27A68C-6001-11D7-9A48-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, March 26, 2003, at 03:21 PM, Naiming Shen wrote: > ] > As long as we are clear that, the "site-local" does not get > special > ] > treatment in terms of routing and dns, we should care less about > if > ] > "site-local" is deprecated or still lived. > ] > ] no. this is not sufficient. apps must not need to care about > ] site-local either. > > If an application choose to care about SL and non-SL, I have no > problem at all. It's not our business to discuss it here no, you have it backwards. the existence of SL forces apps to care about them. > ] nor is it acceptable to treat site-local as a > ] security mechanism. > > If they trust the SL as their security mechanism(like 99% of IPv4 users > do it today), its their problem not to use firewall, but it should not > be forbidden. we can't forbid people from doing stupid things. but neither should we penalize every host, every router, every application in order to allow people to do stupid things. -------------------------------------------------------------------- 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 Mar 26 19:41:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R3fqVV023831; Wed, 26 Mar 2003 19:41:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R3fqFA023830; Wed, 26 Mar 2003 19:41:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R3fnVV023823 for ; Wed, 26 Mar 2003 19:41:49 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R3fvHP015240 for ; Wed, 26 Mar 2003 19:41:57 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16802 for ; Wed, 26 Mar 2003 19:41:52 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:41:39 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:41:39 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:41:39 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 03:41:38 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 6115A6B8363; Wed, 26 Mar 2003 19:41:38 -0800 (PST) To: Keith Moore Cc: Naiming Shen , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from Keith Moore dated Wed, 26 Mar 2003 22:06:33 EST <1D27A68C-6001-11D7-9A48-000393DB5366@cs.utk.edu> Date: Wed, 26 Mar 2003 19:41:38 -0800 From: Naiming Shen Message-Id: <20030327034138.6115A6B8363@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ] ] > ] nor is it acceptable to treat site-local as a ] > ] security mechanism. ] > ] > If they trust the SL as their security mechanism(like 99% of IPv4 users ] > do it today), its their problem not to use firewall, but it should not ] > be forbidden. ] ] we can't forbid people from doing stupid things. but neither should we ] penalize every host, every router, every application in order to allow ] people to do stupid things. ] i can't see your logic that when some hosts "stupidly" using 10.x.x.x address, it actually penalized the hosts/applications who don't use them. if your point is the global reachable hosts can't directly reach those private hosts, well, that is part of the purpose to use private addresses. ] -------------------------------------------------------------------- ] 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 ] -------------------------------------------------------------------- - Naiming -------------------------------------------------------------------- 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 Mar 26 20:41:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R4fXVV024262; Wed, 26 Mar 2003 20:41:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R4fWs4024261; Wed, 26 Mar 2003 20:41:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R4fSVV024254 for ; Wed, 26 Mar 2003 20:41:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R4fbcU023693 for ; Wed, 26 Mar 2003 20:41:37 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15197 for ; Wed, 26 Mar 2003 21:41:32 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 04:41:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 04:31:37 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 04:34:33 Z Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 04:34:32 Z Received: from sdn-ap-028tnnashp0330.dialsprint.net ([209.199.137.76] helo=cs.utk.edu) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yP5q-0005Rl-00; Wed, 26 Mar 2003 20:34:23 -0800 Date: Wed, 26 Mar 2003 23:34:19 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com To: Naiming Shen From: Keith Moore In-Reply-To: <20030327034138.6115A6B8363@prattle.redback.com> Message-Id: <603A67F6-600D-11D7-9A48-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i can't see your logic that when some hosts "stupidly" using 10.x.x.x > address, it actually penalized the hosts/applications who don't use > them. it penalizes all hosts because applications are written for the common case. any app that can't work with scoped addresses has a substantially reduced market. and in order to make apps work with scoped addresses it often requires considerably more complexity in the app, additional infrastructure, etc. so even when the apps work the apps cost more. > if your point is the global reachable hosts can't directly reach > those private hosts, well, that is part of the purpose to use > private addresses. people want it both ways. they want private hosts to be able to participate in apps that reach outside the local net, and they want those hosts to be protected from external threats. but address scoping is the wrong tool for this problem. -------------------------------------------------------------------- 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 Mar 26 21:48:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R5m7VV024785; Wed, 26 Mar 2003 21:48:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R5m7ph024784; Wed, 26 Mar 2003 21:48:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R5m4VV024777 for ; Wed, 26 Mar 2003 21:48:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R5mDcU007159 for ; Wed, 26 Mar 2003 21:48:13 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA20805 for ; Wed, 26 Mar 2003 21:48:07 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 05:48:07 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 05:48:06 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 05:48:06 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 05:48:06 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 939B2F304E; Wed, 26 Mar 2003 21:47:22 -0800 (PST) To: Keith Moore Cc: Naiming Shen , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from Keith Moore dated Wed, 26 Mar 2003 23:34:19 EST <603A67F6-600D-11D7-9A48-000393DB5366@cs.utk.edu> Date: Wed, 26 Mar 2003 21:47:22 -0800 From: Naiming Shen Message-Id: <20030327054722.939B2F304E@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ] > i can't see your logic that when some hosts "stupidly" using 10.x.x.x ] > address, it actually penalized the hosts/applications who don't use ] > them. ] ] it penalizes all hosts because applications are written for the common ] case. any app that can't work with scoped addresses has a ] substantially reduced market. and in order to make apps work with ] scoped addresses it often requires considerably more complexity in the ] app, additional infrastructure, etc. so even when the apps work the ] apps cost more. ok, but if any special routing support for SL is removed, then the only thing left is a private address space for SL. as in ipv4 case, i'm not aware of any application treating 10.x.x.x addr any different from the global routable ones. ] ] > if your point is the global reachable hosts can't directly reach ] > those private hosts, well, that is part of the purpose to use ] > private addresses. ] ] people want it both ways. they want private hosts to be able to ] participate in apps that reach outside the local net, and they want ] those hosts to be protected from external threats. but address scoping ] is the wrong tool for this problem. ] - Naiming -------------------------------------------------------------------- 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 Mar 26 22:05:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R652VV025300; Wed, 26 Mar 2003 22:05:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R6525E025299; Wed, 26 Mar 2003 22:05:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R64vVV025292 for ; Wed, 26 Mar 2003 22:04:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R656HP013116 for ; Wed, 26 Mar 2003 22:05:06 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24796 for ; Wed, 26 Mar 2003 22:05:01 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:05:00 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:05:00 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:05:00 Z Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:05:00 Z Received: from sdn-ap-028tnnashp0481.dialsprint.net ([209.199.137.227] helo=cs.utk.edu) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yQVC-0004Zm-00; Wed, 26 Mar 2003 22:04:38 -0800 Date: Thu, 27 Mar 2003 01:04:35 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com To: Naiming Shen From: Keith Moore In-Reply-To: <20030327054722.939B2F304E@prattle.redback.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ok, but if any special routing support for SL is removed, then the only > thing left is a private address space for SL. as in ipv4 case, i'm not > aware of any application treating 10.x.x.x addr any different from the > global routable ones. many such apps do treat 1918 addresses differently than ordinary addresses, in an attempt to work around problems caused by NATs. -------------------------------------------------------------------- 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 Mar 26 22:10:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R6AcVV025422; Wed, 26 Mar 2003 22:10:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R6Ac6P025421; Wed, 26 Mar 2003 22:10:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R6AYVV025414 for ; Wed, 26 Mar 2003 22:10:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R6AhHP014019 for ; Wed, 26 Mar 2003 22:10:43 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08309 for ; Wed, 26 Mar 2003 23:10:37 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:10:37 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:10:36 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:10:36 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 06:10:36 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id D5BAD72B30F; Wed, 26 Mar 2003 22:10:35 -0800 (PST) To: Keith Moore Cc: Naiming Shen , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from Keith Moore dated Thu, 27 Mar 2003 01:04:35 EST Date: Wed, 26 Mar 2003 22:10:35 -0800 From: Naiming Shen Message-Id: <20030327061035.D5BAD72B30F@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ] > ok, but if any special routing support for SL is removed, then the only ] > thing left is a private address space for SL. as in ipv4 case, i'm not ] > aware of any application treating 10.x.x.x addr any different from the ] > global routable ones. ] ] many such apps do treat 1918 addresses differently than ordinary ] addresses, in an attempt to work around problems caused by NATs. ] then the purpose is to work around the NAT, not necessary related to the private addresses. if for any reason, people still want to use NAT for v6, then those applications still need to adjust. there is no other way around it. i can understand why people hate NAT for various reasons, but private address is not equal to NAT. cheers. - Naiming -------------------------------------------------------------------- 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 Mar 26 23:18:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7ItVV025986; Wed, 26 Mar 2003 23:18:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R7ItcE025985; Wed, 26 Mar 2003 23:18:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7IqVV025978 for ; Wed, 26 Mar 2003 23:18:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R7J1HP028656 for ; Wed, 26 Mar 2003 23:19:01 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22557 for ; Thu, 27 Mar 2003 00:18:55 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:18:55 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:15:59 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:18:54 Z Received: from c001.snv.cp.net ([209.228.32.114] [209.228.32.114]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:18:54 Z Received: (cpmta 23169 invoked from network); 26 Mar 2003 23:18:52 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.114) with SMTP; 26 Mar 2003 23:18:52 -0800 X-Sent: 27 Mar 2003 07:18:52 GMT Message-Id: <002301c2f431$5417b590$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <8DBE3E5E-5FB1-11D7-BCE2-000393DB42B2@nominum.com> Subject: Re: A use for site local addresses? Date: Thu, 27 Mar 2003 09:20:18 +0200 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I suspect you are underestimating the difficulty of renumbering and > overestimating the level of clue of people asked to do the renumbering. > I suspect the list is underestimating the resistance to change that 1000's LAN / WAN people will have to changing both their network and their way of thinking about addresses. We need to make it easy to swallow not just easy to code in the application layer. -------------------------------------------------------------------- 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 Mar 26 23:27:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7RfVV026230; Wed, 26 Mar 2003 23:27:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R7RfCu026229; Wed, 26 Mar 2003 23:27:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7RbVV026222 for ; Wed, 26 Mar 2003 23:27:38 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R7RkcU027983 for ; Wed, 26 Mar 2003 23:27:46 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07188 for ; Wed, 26 Mar 2003 23:27:41 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:27:41 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:24:44 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:27:40 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:27:40 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2R7RV814282; Thu, 27 Mar 2003 09:27:32 +0200 Date: Thu, 27 Mar 2003 09:27:31 +0200 (EET) From: Pekka Savola To: Michel Py cc: Brian Carpenter , Subject: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D28@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 26 Mar 2003, Michel Py wrote: > > Brian E Carpenter > > That's correct as long as the RFC3056 code is only enabled in > > the site border router. If it's enabled in any internal routers, > > the packets will get black holed internally. > > I don't think so. They will be blackholed only if the traffic crosses a > 6to4 tunnel interface, not if the 6to4 address is treated/configured as > a regular IPv6 address. True. (But this was already stated.) > If the routing table contains IGP or connected > routes with a mask of /64 as it should be the longest match route will > prevail over the 2002::/16 route associated with the tunnel interface > and traffic should flow. You're making an assumption that all nodes implementing 6to4 pseudo-intefarce take part in the IGP to get the more specific 2002:FOO routes, or the topology is simple enough that there is only one subnet (, and the site admin expects the default route to do the job). I do not believe this is realistically the case for what's being proposed. > If there is no match in the routing table then > traffic will indeed be blackholed and that's a feature not a bug. True. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 26 23:35:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7ZwVV026455; Wed, 26 Mar 2003 23:35:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R7ZwmA026454; Wed, 26 Mar 2003 23:35:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7ZsVV026447 for ; Wed, 26 Mar 2003 23:35:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R7a1HP002066 for ; Wed, 26 Mar 2003 23:36:01 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20488 for ; Thu, 27 Mar 2003 00:35:56 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:35:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:35:55 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:35:55 Z Received: from c001.snv.cp.net ([209.228.32.122] [209.228.32.122]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:35:55 Z Received: (cpmta 2019 invoked from network); 26 Mar 2003 23:35:52 -0800 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.122) with SMTP; 26 Mar 2003 23:35:52 -0800 X-Sent: 27 Mar 2003 07:35:52 GMT Message-Id: <005101c2f433$b41e28a0$67061eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> Subject: Re: A use for site local addresses? Date: Thu, 27 Mar 2003 09:37:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> People didn't see the need for RFC1918 space in IPv6. > > Because of site-locals. With site-locals gone it is an entirely new ballgame. There is a need for private addresses, > people will use them no matter if they are site-locals, 6to4 addresses with a v4 RFC1918 address or plain hijack > of a global prefix like in the good old days. Then someone will write an RFC to try to contain the hijacks into a > well-known range. I have a sense of déjà vu. I think this is why this is turing out to be such a heated argument. Some of us are trying to learn from history in order to repeate it because we too "have a sense of déjà vu." Others are looking at how hard it will be to implement it at the application layer. I can appriciate this concern. I had a discussion yesterday as to weither in the for seeable future (say 2 - 3 years) I can assume that the customers of my softweare will have a dual stack router as my first hop. OR if I could use the dual stack built into the server OS. Our final decision was that we can not convert our database to pure IPv6 and let the hardware translate for us, so we will have to do it in the appliaction. But knowing this is better if we can avoid having to slap together fixes later for what people will probably do again (i.e. the hijacking of addresses as de facto private). -------------------------------------------------------------------- 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 Mar 26 23:37:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7bOVV026487; Wed, 26 Mar 2003 23:37:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R7bNdm026486; Wed, 26 Mar 2003 23:37:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R7bKVV026476 for ; Wed, 26 Mar 2003 23:37:20 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R7bRcU000143 for ; Wed, 26 Mar 2003 23:37:27 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17331 for ; Wed, 26 Mar 2003 23:37:21 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:37:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:34:24 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:37:20 Z Received: from klapautius.it.su.se ([130.237.91.242] [130.237.91.242]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:37:20 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2R6f0C09045; Thu, 27 Mar 2003 07:41:01 +0100 Message-Id: <3E829CFC.6070802@it.su.se> Date: Thu, 27 Mar 2003 07:41:00 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naiming Shen CC: Keith Moore , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <20030327061035.D5BAD72B30F@prattle.redback.com> In-Reply-To: <20030327061035.D5BAD72B30F@prattle.redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Naiming Shen wrote: > ] > ok, but if any special routing support for SL is removed, then the only > ] > thing left is a private address space for SL. as in ipv4 case, i'm not > ] > aware of any application treating 10.x.x.x addr any different from the > ] > global routable ones. > ] > ] many such apps do treat 1918 addresses differently than ordinary > ] addresses, in an attempt to work around problems caused by NATs. > ] > >then the purpose is to work around the NAT, not necessary related >to the private addresses. if for any reason, people still want to >use NAT for v6, then those applications still need to adjust. there >is no other way around it. i can understand why people hate NAT >for various reasons, but private address is not equal to NAT. > > The problems related to NAT and those related to private addresses are in most cases the same. -------------------------------------------------------------------- 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 Mar 27 00:01:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R81JVV027041; Thu, 27 Mar 2003 00:01:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R81IHt027040; Thu, 27 Mar 2003 00:01:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R81FVV027033 for ; Thu, 27 Mar 2003 00:01:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R81MHP007413 for ; Thu, 27 Mar 2003 00:01:22 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03241 for ; Thu, 27 Mar 2003 01:01:17 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 08:01:16 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 07:58:20 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 08:01:16 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 08:01:15 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id E7B9680F0C3; Thu, 27 Mar 2003 00:01:14 -0800 (PST) To: Leif Johansson Cc: Naiming Shen , Keith Moore , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from Leif Johansson dated Thu, 27 Mar 2003 07:41:00 +0100 <3E829CFC.6070802@it.su.se> Date: Thu, 27 Mar 2003 00:01:14 -0800 From: Naiming Shen Message-Id: <20030327080114.E7B9680F0C3@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i know of some companies employee can be fired by surfing the Internet during work hours. i would think those employee love to have private addresses on their workstations and no NAT devices at all, just in case they don't "accidentally" get fired. you can have many use of private address without NAT involved also. cheers. ] Naiming Shen wrote: ] ] > ] > ok, but if any special routing support for SL is removed, then the onl y ] > ] > thing left is a private address space for SL. as in ipv4 case, i'm not ] > ] > aware of any application treating 10.x.x.x addr any different from the ] > ] > global routable ones. ] > ] ] > ] many such apps do treat 1918 addresses differently than ordinary ] > ] addresses, in an attempt to work around problems caused by NATs. ] > ] ] > ] >then the purpose is to work around the NAT, not necessary related ] >to the private addresses. if for any reason, people still want to ] >use NAT for v6, then those applications still need to adjust. there ] >is no other way around it. i can understand why people hate NAT ] >for various reasons, but private address is not equal to NAT. ] > ] > ] The problems related to NAT and those related to private addresses are ] in most cases the same. ] ] ] -------------------------------------------------------------------- ] 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 ] -------------------------------------------------------------------- - Naiming -------------------------------------------------------------------- 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 Mar 27 00:16:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R8GjVV027316; Thu, 27 Mar 2003 00:16:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2R8GjVZ027315; Thu, 27 Mar 2003 00:16:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2R8GeVV027304 for ; Thu, 27 Mar 2003 00:16:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2R8GlcU008992 for ; Thu, 27 Mar 2003 00:16:47 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10375 for ; Thu, 27 Mar 2003 00:16:46 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 08:16:21 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 08:16:20 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 08:16:20 Z Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 08:16:19 Z Received: from localhost (kame201.kame.net [203.178.141.201]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4C98F15210; Thu, 27 Mar 2003 17:16:20 +0900 (JST) Date: Thu, 27 Mar 2003 17:16:55 +0900 Message-Id: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API In-Reply-To: <200303232146.h2NLkpof071745@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200303232146.h2NLkpof071745@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (In this reply, I'm very specific to the BSD kernel, which may not be appropriate in this list. If the discussion continues on this particular topic, I'll change the place.) >>>>> On Sun, 23 Mar 2003 22:46:51 +0100, >>>>> Francis Dupont said: >> => I have a major concern about the style of the API: it is at the >> socket level ([gs]etsockopt()) when it should be in the context of >> applications: >> - nobody wants to modify every applications in order to use the API >> (an unfortunately many applications can want to toggle one of the >> address selection knobs) >> - at the opposite a global knob is not flexible again. > I tend to agree, but do you have any concrete and feasible suggestion > to implement this? > => in an UNIX context, I can split the question into three parts: > where to put the information, how to manage it, how to use it. > For the place, there are two big options: Okay, and I'm mainly interested in the first two parts (particularly the second one). > - in user or proc structure, i.e., somewhere in the state of the process, > exactly like user credentials with possible sharing, etc. > - in environment variables, i.e., like RES_OPTIONS for tuning of > the resolver library via the process context. > In the second case, the obvious managing functions are [gs]etenv() but > this makes a textual form of tuning tables and knobs necessary. > In the first case, the best is to add a sysctl() like you already did > for the policy table. An inheritance rule completes this part. > There are two main ways to use the information: inside the kernel (like > the policy table or the proposed [gs]etsockopt()) or inside the standard > library (like the current resolver tuning). > Try first with the policy table (because you have already a good support > for a global one and because it is the main way to tune address selection, > i.e., I already use it on some multi-homed nodes and there are some cases > where I'd like to have a per-application policy). I've once considered similar approaches. I didn't go further at that time, because: - a sysctl-like approach would require a big change in the kernel. We'd need to modify the proc structure and one/several files under the sys/kern directory. I could not be sure if this kind of change was ever widely accepted for this particular purpose. - using environment variables seemed a good approach in terms of the impact on the kernel internal code. However, it is (possible but) not very easy to manipulate the env. variables within the kernel. I'd also like to avoid complicated string operations in the kernel. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- 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 Mar 27 03:24:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RBOGVV028358; Thu, 27 Mar 2003 03:24:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RBOGbi028357; Thu, 27 Mar 2003 03:24:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RBODVV028350 for ; Thu, 27 Mar 2003 03:24:13 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RBOLcU021254 for ; Thu, 27 Mar 2003 03:24:21 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06223 for ; Thu, 27 Mar 2003 03:24:15 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:24:15 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:24:14 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:24:14 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:24:14 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id D91388985; Thu, 27 Mar 2003 12:24:10 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 320578574; Thu, 27 Mar 2003 12:24:04 +0100 (CET) From: "Jeroen Massar" To: "'Naiming Shen'" Cc: Subject: RE: A use for site local addresses? Date: Thu, 27 Mar 2003 12:25:07 +0100 Organization: Unfix Message-Id: <001001c2f453$86f4ac80$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030327080114.E7B9680F0C3@prattle.redback.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Naiming Shen wrote: > i know of some companies employee can be fired by surfing the > Internet during work hours. i would think those employee love to > have private addresses on their workstations and no NAT devices at > all, just in case they don't "accidentally" get fired. you can > have many use of private address without NAT involved also. Either do ip -6 ro add default ::1 Or disable your DNS to be able to do global lookups. Or pull the plug from your uplink. Or ... This is a firewalling and more over a personal issue. I could just as well flip out my new IPv6 Cellphone and browse the web with that. If the employee really wants to he will. If you don't want to get to the internet on a network just don't route it. Nobody stated that allocated prefixes should be routed onto the internet now did they? I don't see any reason whatsoever why having a special address space set aside for a reason like this could have any advantage. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 27 03:37:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RBbLVV028617; Thu, 27 Mar 2003 03:37:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RBbLnH028615; Thu, 27 Mar 2003 03:37:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RBbHVV028604 for ; Thu, 27 Mar 2003 03:37:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RBbPcU024082 for ; Thu, 27 Mar 2003 03:37:25 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16185 for ; Thu, 27 Mar 2003 04:37:19 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:37:19 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:34:22 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:37:18 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 11:37:17 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 3A63A898B; Thu, 27 Mar 2003 12:37:13 +0100 (CET) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id E67AB8984; Thu, 27 Mar 2003 12:37:07 +0100 (CET) From: "Jeroen Massar" To: "'EricLKlein'" , Subject: RE: A use for site local addresses? Date: Thu, 27 Mar 2003 12:38:12 +0100 Organization: Unfix Message-Id: <001801c2f455$598e7120$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <005101c2f433$b41e28a0$67061eac@ttitelecom.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2RBbHVV028605 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: Who did you qoute here again? > > >> People didn't see the need for RFC1918 space in IPv6. > > > > Because of site-locals. With site-locals gone it is an entirely new > ballgame. There is a need for private addresses, > Others are looking at how hard it will be to implement it at > the application layer. I can appriciate this concern. I had a > discussion yesterday as to weither in the for seeable future > (say 2 - 3 years) I can assume that the customers of my > softweare will have a dual stack router as my first hop. OR > if I could use the dual stack built into the server OS. Our > final decision was that we can not convert our database to > pure IPv6 and let the hardware translate for us, so we will > have to do it in the appliaction. If you want to code IPv4 & IPv6 aware programs then check http://www.kame.net/newsletter/19980604/ which contains Jun-ichiro itojun Itoh's Implementing AF-independent application. That document is almost 5 years old now and has been used by many application porters. Another good document is written by Eva M. Castro and can be found at http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html and it isn't called "Porting applications to IPv6 HowTo" for nothing. Includes TCP, UDP and multicast examples. I wonder why you even thought about 'converting your database' to 'pure IPv6' while IPv4 will be here to stay for quite some time. IPv4 came quite fast and it will stick around for some time too. Ofcourse the app will have to have knowledge of both IPv4 and IPv6, but if you are a smart coder you use the functions as described in the above two documents which both talk about making your application AF independent, aka there will be no knowledge about IPv4/IPv6 and theoretically even IPX. Still an application should then not be aware of something like 'sitelocal', to get back to the subject becaue in AF independent world there is no such thing. An app just send data from A to B. And shouldn't be caring about address prefixes. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 27 05:54:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RDshVV029134; Thu, 27 Mar 2003 05:54:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RDshpA029133; Thu, 27 Mar 2003 05:54:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RDsdVV029126 for ; Thu, 27 Mar 2003 05:54:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RDslcU019530 for ; Thu, 27 Mar 2003 05:54:47 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21852 for ; Thu, 27 Mar 2003 06:54:41 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:54:41 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:54:38 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:54:38 Z Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:54:37 Z Received: from sdn-ap-028tnnashp0460.dialsprint.net ([209.199.137.206] helo=cs.utk.edu) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yXpt-0007ZJ-00; Thu, 27 Mar 2003 05:54:30 -0800 Date: Thu, 27 Mar 2003 08:54:27 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com To: Naiming Shen From: Keith Moore In-Reply-To: <20030327061035.D5BAD72B30F@prattle.redback.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, March 27, 2003, at 01:10 AM, Naiming Shen wrote: > ] > ok, but if any special routing support for SL is removed, then > the only > ] > thing left is a private address space for SL. as in ipv4 case, > i'm not > ] > aware of any application treating 10.x.x.x addr any different > from the > ] > global routable ones. > ] > ] many such apps do treat 1918 addresses differently than ordinary > ] addresses, in an attempt to work around problems caused by NATs. > ] > > then the purpose is to work around the NAT, not necessary related > to the private addresses. no, the purpose is to work around both NAT and scoped addresses. NAT imposes limitations that scoped addresses do not (because the address is changed in transit and because NATs typically impose limitations on the direction in which a communication can be established). but scoped addresses impose limitations whether or not NAT is used. > if for any reason, people still want to > use NAT for v6, then those applications still need to adjust. no, IPv6 needs to adjust to not use scoped addresses. > i can understand why people hate NAT > for various reasons, but private address is not equal to NAT. not equal, but similar. Keith -------------------------------------------------------------------- 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 Mar 27 05:55:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RDtlVV029153; Thu, 27 Mar 2003 05:55:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RDtlK2029152; Thu, 27 Mar 2003 05:55:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RDtgVV029145 for ; Thu, 27 Mar 2003 05:55:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RDtoHP015260 for ; Thu, 27 Mar 2003 05:55:50 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18545 for ; Thu, 27 Mar 2003 06:55:44 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:55:43 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:52:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:55:40 Z Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 13:55:39 Z Received: from sdn-ap-028tnnashp0460.dialsprint.net ([209.199.137.206] helo=cs.utk.edu) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18yXqv-000160-00; Thu, 27 Mar 2003 05:55:33 -0800 Date: Thu, 27 Mar 2003 08:55:30 -0500 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Keith Moore , Leif Johansson , alh-ietf@tndh.net, "'Kurt Erik Lindqvist'" , "'EricLKlein'" , ipng@sunroof.eng.sun.com To: Naiming Shen From: Keith Moore In-Reply-To: <20030327080114.E7B9680F0C3@prattle.redback.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i know of some companies employee can be fired by surfing the > Internet during work hours. i would think those employee love to > have private addresses on their workstations and no NAT devices at > all, just in case they don't "accidentally" get fired. so we should cripple the v6 architecture just so some brain-dead company can't be bothered to block port 80? -------------------------------------------------------------------- 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 Mar 27 07:48:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RFm0VV000273; Thu, 27 Mar 2003 07:48:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RFlxnQ000272; Thu, 27 Mar 2003 07:47:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RFluVV000262 for ; Thu, 27 Mar 2003 07:47:56 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RFm4cU020654 for ; Thu, 27 Mar 2003 07:48:04 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05053 for ; Thu, 27 Mar 2003 07:47:58 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 15:47:57 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 15:47:57 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 15:47:57 Z Received: from web14801.mail.yahoo.com (web14801.mail.yahoo.com [216.136.224.217]) by relay2.sun.com for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 15:47:56 Z Message-Id: <20030327154755.24839.qmail@web14801.mail.yahoo.com> Received: from [65.213.193.49] by web14801.mail.yahoo.com via HTTP; Thu, 27 Mar 2003 07:47:55 PST Date: Thu, 27 Mar 2003 07:47:55 -0800 (PST) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Papers To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-201940890-1048780075=:24789" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-201940890-1048780075=:24789 Content-Type: text/plain; charset=us-ascii Dear Colleagues: Our sincere apologies if you receive multiple copies of this announcement. CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS Internetworking 2003 June 22-24, 2003 San Jose, California In technical cooperation with IEEE, IFIP, and ACM (Pending) Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: - Voice over IP (VoIP) - IP Video Conferencing - Storage Area Networks (SANs) - Unicast and Multicast Routing and Convergence - QoS Routing - Network Security and Service Integration - Operational Support Systems - Virtual Private Networks - Internetworking Wireless LANs and 3G Wireless Networks - IP-based Infrastructure for Wireless Networks - Internetworking IP and Optical Networks - Internetworking MPLS with Legacy ATM and Frame Relay Networks - Transition from IPv4 to IPv6 and interworking - Pervasive Computing - High Speed Transport Layer Protocols - Peer to Peer Networking and Grid Computing - Video Teleconferencing (VTC) - 802.11 Hotspots The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE , or Daniel Awduche . --0-201940890-1048780075=:24789 Content-Type: text/html; charset=us-ascii

Dear Colleagues:

Our sincere apologies if you receive multiple copies of this announcement.

     CONFERENCE ANNOUNCEMENT AND CALL FOR PRESENTATIONS

                   Internetworking 2003
                      June 22-24, 2003
                   San Jose, California
      In technical cooperation with IEEE, IFIP, and ACM (Pending)


Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following:

- Voice over IP (VoIP)
- IP Video Conferencing
- Storage Area Networks (SANs)
- Unicast and Multicast Routing and Convergence
- QoS Routing
- Network Security and Service Integration
- Operational Support Systems
- Virtual Private Networks
- Internetworking Wireless LANs and 3G Wireless Networks
- IP-based Infrastructure for Wireless Networks
- Internetworking IP and Optical Networks
- Internetworking MPLS with Legacy ATM and Frame Relay Networks
- Transition from IPv4 to IPv6 and interworking
- Pervasive Computing
- High Speed Transport Layer Protocols
- Peer to Peer Networking and Grid Computing
- Video Teleconferencing (VTC)
- 802.11 Hotspots


The Internetworking 2003 event in June will include participation from industry, government agencies, and academia. If you need additional technical information, please contact the Technical Cochairs Professor Maurice GAGNAIRE <gagnaire@enst.fr>, or Daniel Awduche <Awduche@awduche.com>.

--0-201940890-1048780075=:24789-- -------------------------------------------------------------------- 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 Mar 27 08:49:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RGniVV000731; Thu, 27 Mar 2003 08:49:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RGniUv000730; Thu, 27 Mar 2003 08:49:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RGnfVV000722 for ; Thu, 27 Mar 2003 08:49:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RGnncU008110 for ; Thu, 27 Mar 2003 08:49:49 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14052 for ; Thu, 27 Mar 2003 09:49:43 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:49:42 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:49:38 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:49:38 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:49:38 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2RGnaSo058958 for ; Thu, 27 Mar 2003 17:49:36 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2RGnaEx266582 for ; Thu, 27 Mar 2003 17:49:36 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28666 from ; Thu, 27 Mar 2003 17:49:34 +0100 Message-Id: <3E832B5B.BDECDB3A@hursley.ibm.com> Date: Thu, 27 Mar 2003 17:48:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Wed, 26 Mar 2003, Michel Py wrote: > > > Brian E Carpenter > > > That's correct as long as the RFC3056 code is only enabled in > > > the site border router. If it's enabled in any internal routers, > > > the packets will get black holed internally. > > > > I don't think so. They will be blackholed only if the traffic crosses a > > 6to4 tunnel interface, not if the 6to4 address is treated/configured as > > a regular IPv6 address. > > True. (But this was already stated.) It's exactly what I said: RFC 3056 code is the only code that will blackhole these packets. > > > If the routing table contains IGP or connected > > routes with a mask of /64 as it should be the longest match route will > > prevail over the 2002::/16 route associated with the tunnel interface > > and traffic should flow. > > You're making an assumption that all nodes implementing 6to4 > pseudo-intefarce take part in the IGP to get the more specific 2002:FOO > routes, or the topology is simple enough that there is only one subnet (, > and the site admin expects the default route to do the job). > > I do not believe this is realistically the case for what's being proposed. I'm confused. When one is inside the border at which an RFC 3056 router is placed, 6to4 addresses are exactly like any other native IPv6 address. No host inside that border should have a 6to4 pseudo-interface. > > > If there is no match in the routing table then > > traffic will indeed be blackholed and that's a feature not a bug. > > True. True, but not specific to 6to4 addresses. Again, they are only special in one place: a border router that has RFC 3056 switched on. Brian -------------------------------------------------------------------- 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 Mar 27 08:55:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RGtOVV000923; Thu, 27 Mar 2003 08:55:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RGtNWY000922; Thu, 27 Mar 2003 08:55:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RGtKVV000915 for ; Thu, 27 Mar 2003 08:55:20 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RGtScU010045 for ; Thu, 27 Mar 2003 08:55:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20877 for ; Thu, 27 Mar 2003 08:55:22 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:55:20 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:55:20 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:55:19 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:55:19 Z Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 2003 08:55:16 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D30@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Thread-Index: AcL0MlfxwShiXdeDRUuQ+ZjaYiKEQgATljWA From: "Michel Py" To: "Pekka Savola" Cc: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2RGtKVV000916 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> If the routing table contains IGP or connected routes with >> a mask of /64 as it should be the longest match route will >> prevail over the 2002::/16 route associated with the tunnel >> interface and traffic should flow. > Pekka Savola wrote: > You're making an assumption that all nodes implementing 6to4 > pseudo-intefarce take part in the IGP to get the more specific > 2002:FOO routes, Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 pseudo-interfaces (or have it deactivated). > or the topology is simple enough that there is only one subnet No. The point is multiple subnets indeed. > (and the site admin expects the default route to do the job). Yes. Default route on a given subnet points to the router. The router participates in the IGP and has specific routes. > I do not believe this is realistically the case for what's > being proposed. For what reasons? Michel. -------------------------------------------------------------------- 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 Mar 27 08:57:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RGvWVV001014; Thu, 27 Mar 2003 08:57:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RGvVK3001012; Thu, 27 Mar 2003 08:57:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RGvSVV001005 for ; Thu, 27 Mar 2003 08:57:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RGvacU010818 for ; Thu, 27 Mar 2003 08:57:36 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24305 for ; Thu, 27 Mar 2003 09:57:31 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:57:28 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:57:27 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:57:27 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 16:57:27 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2RGvON19459; Thu, 27 Mar 2003 18:57:24 +0200 Date: Thu, 27 Mar 2003 18:57:24 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] In-Reply-To: <3E832B5B.BDECDB3A@hursley.ibm.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 27 Mar 2003, Brian E Carpenter wrote: > > > If the routing table contains IGP or connected > > > routes with a mask of /64 as it should be the longest match route will > > > prevail over the 2002::/16 route associated with the tunnel interface > > > and traffic should flow. > > > > You're making an assumption that all nodes implementing 6to4 > > pseudo-intefarce take part in the IGP to get the more specific 2002:FOO > > routes, or the topology is simple enough that there is only one subnet (, > > and the site admin expects the default route to do the job). > > > > I do not believe this is realistically the case for what's being proposed. > > I'm confused. When one is inside the border at which an RFC 3056 router is > placed, 6to4 addresses are exactly like any other native IPv6 address. Yep. (For nodes which don't have 6to4 pseudo-interface enabled, of course.) > No host inside that border should have a 6to4 pseudo-interface. But in reality, they do. Some implementations even enable it automatically. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 27 09:00:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RH0UVV001139; Thu, 27 Mar 2003 09:00:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RH0UsX001138; Thu, 27 Mar 2003 09:00:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RH0RVV001128 for ; Thu, 27 Mar 2003 09:00:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RH0ZHP006499 for ; Thu, 27 Mar 2003 09:00:35 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09532 for ; Thu, 27 Mar 2003 10:00:29 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:00:12 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:00:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:00:10 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:00:09 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2RH03519494; Thu, 27 Mar 2003 19:00:04 +0200 Date: Thu, 27 Mar 2003 19:00:03 +0200 (EET) From: Pekka Savola To: Michel Py cc: Brian Carpenter , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54D30@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 27 Mar 2003, Michel Py wrote: > >> Michel Py wrote: > >> If the routing table contains IGP or connected routes with > >> a mask of /64 as it should be the longest match route will > >> prevail over the 2002::/16 route associated with the tunnel > >> interface and traffic should flow. > > > Pekka Savola wrote: > > You're making an assumption that all nodes implementing 6to4 > > pseudo-intefarce take part in the IGP to get the more specific > > 2002:FOO routes, > > Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 > pseudo-interfaces (or have it deactivated). There is no such statement anywhere that I know of. Please correct me if I'm wrong. Hosts indeed have 6to4 pseudo-interfaces. > > I do not believe this is realistically the case for what's > > being proposed. > > For what reasons? See above. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 27 09:09:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RH9oVV001663; Thu, 27 Mar 2003 09:09:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RH9oo0001662; Thu, 27 Mar 2003 09:09:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RH9kVV001653 for ; Thu, 27 Mar 2003 09:09:46 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RH9scU015913 for ; Thu, 27 Mar 2003 09:09:55 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10398 for ; Thu, 27 Mar 2003 09:09:49 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:09:48 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:09:47 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:09:47 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:09:47 Z Content-class: urn:content-classes:message Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 2003 09:09:45 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D31@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Thread-Index: AcL0glFTWJ0YKgssRtmDXVNa6KKEfgAAB75g From: "Michel Py" To: "Pekka Savola" Cc: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2RH9lVV001656 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> Well, yes but these nodes are only routers. Hosts MUST NOT >> have any 6to4 pseudo-interfaces (or have it deactivated). > Pekka Savola wrote: > There is no such statement anywhere that I know of. Please > correct me if I'm wrong. Hosts indeed have 6to4 pseudo-interfaces. > Brian Carpenter wrote: > I'm confused. When one is inside the border at which an RFC > 3056 router is placed, 6to4 addresses are exactly like any > other native IPv6 address. No host inside that border should > have a 6to4 pseudo-interface. Exactly. So the requirements for a site to use 2002:0A00::/24 as a "private" address are no different than those for 6to4 site to use the border router's v4 address as the 6to4 address. In other words, a site that would want to use 2002:0A00::/24 as a private addressing scheme is just like any regular 6to4 site except that it does not have the 6to4 gateway. >> No host inside that border should have a 6to4 >> pseudo-interface. > But in reality, they do. Some implementations even > enable it automatically. Again, this is my very point: using 2002:0A00::/24 as a "private" address will _enforce_ the need to disable these interfaces (because if they're enabled they blackhole the traffic and nothing works), which is a feature not a bug for a private network. Michel. -------------------------------------------------------------------- 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 Mar 27 09:11:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHBTVV001734; Thu, 27 Mar 2003 09:11:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RHBSZ4001733; Thu, 27 Mar 2003 09:11:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHBPVV001723 for ; Thu, 27 Mar 2003 09:11:25 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RHBXHP010475 for ; Thu, 27 Mar 2003 09:11:33 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05895 for ; Thu, 27 Mar 2003 09:11:27 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:11:18 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:11:14 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:11:14 Z Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:11:14 Z Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 27 Mar 2003 09:11:12 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Mar 2003 09:11:05 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 27 Mar 2003 09:10:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 27 Mar 2003 09:11:08 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Thu, 27 Mar 2003 09:11:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Date: Thu, 27 Mar 2003 09:11:15 -0800 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Thread-Index: AcL0MlfxwShiXdeDRUuQ+ZjaYiKEQgATljWAAAB915A= From: "Christian Huitema" To: "Michel Py" , "Pekka Savola" Cc: "Brian Carpenter" , X-OriginalArrivalTime: 27 Mar 2003 17:11:08.0973 (UTC) FILETIME=[DC1015D0:01C2F483] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2RHBPVV001724 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > You're making an assumption that all nodes implementing 6to4 > > pseudo-intefarce take part in the IGP to get the more specific > > 2002:FOO routes, > > Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 > pseudo-interfaces (or have it deactivated). Making rules as we speak, uh? At most, you are saying that a node that has a 6to4 interface should be called a router. Fine. What have you achieved? You only get control if you can convince a specific node to not activate a particular function, i.e. if you had control over the node in the first place. It is reasonable to expect nodes who receive an RA for 2002:F00::, or for that matter 2002:DEAD:BEEF::, to route packets bound to that specific prefix towards the interface over which they received the RA. But it is also not unreasonable to expect nodes to drop packets bound to illegal 2002:: addresses, and possibly ignore advertisements of illegal prefixes. -- Christian Huitema -------------------------------------------------------------------- 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 Mar 27 09:13:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHD8VV001808; Thu, 27 Mar 2003 09:13:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RHD8ht001807; Thu, 27 Mar 2003 09:13:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHD3VV001794 for ; Thu, 27 Mar 2003 09:13:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RHDCcU017279 for ; Thu, 27 Mar 2003 09:13:12 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07315 for ; Thu, 27 Mar 2003 09:13:06 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:13:05 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:13:05 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:13:05 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:13:04 Z Content-class: urn:content-classes:message Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 2003 09:13:03 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045602@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Thread-Index: AcL0MlfxwShiXdeDRUuQ+ZjaYiKEQgATljWAAAB915AAAFc0MA== From: "Michel Py" To: "Christian Huitema" , "Pekka Savola" Cc: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2RHD4VV001795 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Christian Huitema wrote: > Making rules as we speak, uh? Nope, see Brian's post. Nothing new in this. Michel. -------------------------------------------------------------------- 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 Mar 27 09:48:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHm5VV003310; Thu, 27 Mar 2003 09:48:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RHm5io003309; Thu, 27 Mar 2003 09:48:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHm2VV003302 for ; Thu, 27 Mar 2003 09:48:02 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RHmAHP023587 for ; Thu, 27 Mar 2003 09:48:10 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03673 for ; Thu, 27 Mar 2003 09:48:04 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:47:16 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:44:19 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:47:16 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:47:15 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2RHlDEO020958 for ; Thu, 27 Mar 2003 18:47:13 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2RHlCEx216138 for ; Thu, 27 Mar 2003 18:47:13 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32292 from ; Thu, 27 Mar 2003 18:47:11 +0100 Message-Id: <3E8338DC.495389E@hursley.ibm.com> Date: Thu, 27 Mar 2003 18:46:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <20030327000856.2FFCA868F2B@prattle.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Naiming Shen wrote: ... > though i'm absolutely against to have routing/dns > support to SL. SL's have to be routed within the site anyway, and probably have to be in local DNS to be of any use, which pretty much forces the use of two-faced DNS to avoid accidentally exporting them. In other words, the only sure way to avoid routing and DNS support for SLs is to abolish them. Brian -------------------------------------------------------------------- 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 Mar 27 09:51:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHpMVV003390; Thu, 27 Mar 2003 09:51:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RHpMWm003389; Thu, 27 Mar 2003 09:51:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RHpIVV003382 for ; Thu, 27 Mar 2003 09:51:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RHpRHP024839 for ; Thu, 27 Mar 2003 09:51:27 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14119 for ; Thu, 27 Mar 2003 10:51:21 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:48:16 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:40:08 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:40:08 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:40:07 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2RHclEO026952; Thu, 27 Mar 2003 18:38:47 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2RHcjEx236812; Thu, 27 Mar 2003 18:38:46 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51624 from ; Thu, 27 Mar 2003 18:38:39 +0100 Message-Id: <3E8336DB.FB6A478D@hursley.ibm.com> Date: Thu, 27 Mar 2003 18:37:31 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: EricLKlein Cc: ipng@sunroof.eng.sun.com Subject: dual stack [Re: A use for site local addresses?] References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> <005101c2f433$b41e28a0$67061eac@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: ... > Our final decision > was that we can not convert our database to pure IPv6 and let the hardware > translate for us, so we will have to do it in the appliaction. Of course. Full dual stack support is the only rational starting point; all the other coexistence mechanisms are second best. Brian -------------------------------------------------------------------- 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 Mar 27 10:01:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RI11VV004026; Thu, 27 Mar 2003 10:01:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RI11DZ004025; Thu, 27 Mar 2003 10:01:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RI0vVV004015 for ; Thu, 27 Mar 2003 10:00:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RI15cU007158 for ; Thu, 27 Mar 2003 10:01:05 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25586 for ; Thu, 27 Mar 2003 11:00:59 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 12:03:03 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:59:57 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 17:59:57 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 12:02:31 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2RI0gVj020834; Thu, 27 Mar 2003 20:00:43 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2RI0eOi020833; Thu, 27 Mar 2003 20:00:40 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] From: Mika Liljeberg To: Pekka Savola Cc: Michel Py , Brian Carpenter , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048788040.15490.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 20:00:40 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-03-27 at 19:00, Pekka Savola wrote: > > Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 > > pseudo-interfaces (or have it deactivated). > > There is no such statement anywhere that I know of. Please correct me if > I'm wrong. Hosts indeed have 6to4 pseudo-interfaces. You're right. However, I think it's just common sense that a host, which sets up a 6to4 pseudo interface by default, should also automatically disable it if a router is sending RAs with 2002:xyz:: prefixes. Otherwise the host implementation is broken. MikaL -------------------------------------------------------------------- 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 Mar 27 10:22:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIMwVV004485; Thu, 27 Mar 2003 10:22:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RIMvuK004484; Thu, 27 Mar 2003 10:22:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIMsVV004477 for ; Thu, 27 Mar 2003 10:22:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RIN2HP008138 for ; Thu, 27 Mar 2003 10:23:02 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16817 for ; Thu, 27 Mar 2003 11:22:57 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:22:56 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:22:56 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:22:55 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:22:55 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2RIMnf20320; Thu, 27 Mar 2003 20:22:49 +0200 Date: Thu, 27 Mar 2003 20:22:48 +0200 (EET) From: Pekka Savola To: Mika Liljeberg cc: Michel Py , Brian Carpenter , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] In-Reply-To: <1048788040.15490.12.camel@devil> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 27 Mar 2003, Mika Liljeberg wrote: > On Thu, 2003-03-27 at 19:00, Pekka Savola wrote: > > > Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 > > > pseudo-interfaces (or have it deactivated). > > > > There is no such statement anywhere that I know of. Please correct me if > > I'm wrong. Hosts indeed have 6to4 pseudo-interfaces. > > You're right. However, I think it's just common sense that a host, which > sets up a 6to4 pseudo interface by default, should also automatically > disable it if a router is sending RAs with 2002:xyz:: prefixes. > Otherwise the host implementation is broken. Maybe, maybe not. In many cases, the node implementations include both host and router behaviour. In such case, automatically disabling something may not be the best option. This may be something worth fleshing out when/if we progress 6to4 to DS at some point :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 27 10:33:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIX4VV004676; Thu, 27 Mar 2003 10:33:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RIX3rq004675; Thu, 27 Mar 2003 10:33:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIX0VV004665 for ; Thu, 27 Mar 2003 10:33:00 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RIX8HP011988 for ; Thu, 27 Mar 2003 10:33:08 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13834 for ; Thu, 27 Mar 2003 10:33:03 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:33:02 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:33:01 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:33:01 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:32:40 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Mar 2003 10:32:53 -0800 Reply-To: From: "Tony Hain" To: "'Mika Liljeberg'" , "'Pekka Savola'" Cc: "'Michel Py'" , "'Brian Carpenter'" , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Date: Thu, 27 Mar 2003 10:32:55 -0800 Message-Id: <054201c2f48f$48ac7e80$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1048788040.15490.12.camel@devil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika Liljeberg wrote: > You're right. However, I think it's just common sense that a > host, which sets up a 6to4 pseudo interface by default, > should also automatically disable it if a router is sending > RAs with 2002:xyz:: prefixes. Otherwise the host > implementation is broken. Not necessarily. As long as the RA based prefix has a lower metric than the local pseudo interface, there is no reason to disable it. Depending on the implementation, this might allow for a faster recovery when the RA disappears. Tony -------------------------------------------------------------------- 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 Mar 27 10:35:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIZ6VV004740; Thu, 27 Mar 2003 10:35:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RIZ6rl004739; Thu, 27 Mar 2003 10:35:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIZ2VV004726 for ; Thu, 27 Mar 2003 10:35:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RIZAcU020655 for ; Thu, 27 Mar 2003 10:35:10 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06431 for ; Thu, 27 Mar 2003 11:35:02 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:35:00 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:34:59 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:34:58 Z Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:34:58 Z Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2RIYi4c010333; Thu, 27 Mar 2003 10:34:45 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA05374; Thu, 27 Mar 2003 18:34:44 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Pekka Savola Cc: Mika Liljeberg , Michel Py , Brian Carpenter , Subject: Re: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] From: Ole Troan Date: Thu, 27 Mar 2003 18:34:44 +0000 In-Reply-To: (Pekka Savola's message of "Thu, 27 Mar 2003 20:22:48 +0200 (EET)") Message-Id: <7t5y930y7y3.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On 27 Mar 2003, Mika Liljeberg wrote: >> On Thu, 2003-03-27 at 19:00, Pekka Savola wrote: >> > > Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 >> > > pseudo-interfaces (or have it deactivated). >> > >> > There is no such statement anywhere that I know of. Please correct me if >> > I'm wrong. Hosts indeed have 6to4 pseudo-interfaces. >> >> You're right. However, I think it's just common sense that a host, which >> sets up a 6to4 pseudo interface by default, should also automatically >> disable it if a router is sending RAs with 2002:xyz:: prefixes. >> Otherwise the host implementation is broken. it should disable it for any received RA, i.e when it is on a native link. > Maybe, maybe not. In many cases, the node implementations include both > host and router behaviour. In such case, automatically disabling > something may not be the best option. > > This may be something worth fleshing out when/if we progress 6to4 to DS > at some point :-) a host connected to a native link should not automatically enable a 6to4 pseudo interface. /ot -------------------------------------------------------------------- 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 Mar 27 10:47:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIlNVV005268; Thu, 27 Mar 2003 10:47:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RIlN8j005267; Thu, 27 Mar 2003 10:47:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIlJVV005259 for ; Thu, 27 Mar 2003 10:47:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RIlRHP017805 for ; Thu, 27 Mar 2003 10:47:28 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09166 for ; Thu, 27 Mar 2003 11:47:22 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:47:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:44:18 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:47:15 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:47:14 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2RIlDSo030624 for ; Thu, 27 Mar 2003 19:47:13 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2RIlAEx223514 for ; Thu, 27 Mar 2003 19:47:11 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA22866 from ; Thu, 27 Mar 2003 19:47:08 +0100 Message-Id: <3E8346E8.E28B7E10@hursley.ibm.com> Date: Thu, 27 Mar 2003 19:46:00 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Thu, 27 Mar 2003, Michel Py wrote: > > >> Michel Py wrote: > > >> If the routing table contains IGP or connected routes with > > >> a mask of /64 as it should be the longest match route will > > >> prevail over the 2002::/16 route associated with the tunnel > > >> interface and traffic should flow. > > > > > Pekka Savola wrote: > > > You're making an assumption that all nodes implementing 6to4 > > > pseudo-intefarce take part in the IGP to get the more specific > > > 2002:FOO routes, > > > > Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 > > pseudo-interfaces (or have it deactivated). > > There is no such statement anywhere that I know of. Please correct me if > I'm wrong. Hosts indeed have 6to4 pseudo-interfaces. > RFC 3056 mainly talks about routers and strongly implies what Michel says, but that MUST NOT is not in any RFC. Some hosts can support such a pseudo-interface, but having it on by default is a problem IMHO. Brian -------------------------------------------------------------------- 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 Mar 27 10:47:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIlnVV005305; Thu, 27 Mar 2003 10:47:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RIln4V005304; Thu, 27 Mar 2003 10:47:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RIlhVV005290 for ; Thu, 27 Mar 2003 10:47:44 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RIlqcU025757 for ; Thu, 27 Mar 2003 10:47:52 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00721 for ; Thu, 27 Mar 2003 10:47:46 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:47:36 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:47:29 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:47:28 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:47:28 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2RImIVj021088; Thu, 27 Mar 2003 20:48:18 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2RImG12021087; Thu, 27 Mar 2003 20:48:16 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] From: Mika Liljeberg To: alh-ietf@tndh.net Cc: "'Pekka Savola'" , "'Michel Py'" , "'Brian Carpenter'" , ipng@sunroof.eng.sun.com In-Reply-To: <054201c2f48f$48ac7e80$ee1a4104@eagleswings> References: <054201c2f48f$48ac7e80$ee1a4104@eagleswings> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048790896.15484.17.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 20:48:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-03-27 at 20:32, Tony Hain wrote: > Not necessarily. As long as the RA based prefix has a lower metric than > the local pseudo interface, there is no reason to disable it. Depending > on the implementation, this might allow for a faster recovery when the > RA disappears. Nope. If your network uses 6to4 addressing, you probably want to send off-link 6to4 destinations to your default router rather than the local 6to4 pseudo interface. MikaL -------------------------------------------------------------------- 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 Mar 27 10:48:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RImlVV005334; Thu, 27 Mar 2003 10:48:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RImlde005333; Thu, 27 Mar 2003 10:48:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RImhVV005323 for ; Thu, 27 Mar 2003 10:48:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RImpHP018349 for ; Thu, 27 Mar 2003 10:48:51 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10488 for ; Thu, 27 Mar 2003 11:48:45 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:48:44 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:48:44 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:48:44 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 18:48:44 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Mar 2003 10:48:42 -0800 Reply-To: From: "Tony Hain" To: "'Ole Troan'" , "'Pekka Savola'" Cc: "'Mika Liljeberg'" , "'Michel Py'" , "'Brian Carpenter'" , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Date: Thu, 27 Mar 2003 10:48:43 -0800 Message-Id: <054301c2f491$7da4e8f0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <7t5y930y7y3.fsf@mrwint.cisco.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole Troan wrote: > it should disable it for any received RA, i.e when it is on a > native link. No, because this would force traffic to 6to4 sites through a relay. The RA receiving interface should be the path to default, and the 6to4 interface should be used for those prefixes. > a host connected to a native link should not automatically > enable a 6to4 pseudo interface. See above. Tony -------------------------------------------------------------------- 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 Mar 27 11:04:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJ4cVV006235; Thu, 27 Mar 2003 11:04:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJ4cM4006234; Thu, 27 Mar 2003 11:04:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJ4YVV006227 for ; Thu, 27 Mar 2003 11:04:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJ4gHP024588 for ; Thu, 27 Mar 2003 11:04:42 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25090 for ; Thu, 27 Mar 2003 12:04:37 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:04:36 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:04:36 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:04:36 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:04:35 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Mar 2003 11:04:34 -0800 Reply-To: From: "Tony Hain" To: "'Mika Liljeberg'" Cc: "'Pekka Savola'" , "'Michel Py'" , "'Brian Carpenter'" , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Date: Thu, 27 Mar 2003 11:04:35 -0800 Message-Id: <054801c2f493$b581d5b0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1048790896.15484.17.camel@devil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika Liljeberg wrote: > On Thu, 2003-03-27 at 20:32, Tony Hain wrote: > > Not necessarily. As long as the RA based prefix has a lower metric > > than the local pseudo interface, there is no reason to disable it. > > Depending on the implementation, this might allow for a faster > > recovery when the RA disappears. > > Nope. If your network uses 6to4 addressing, you probably want > to send off-link 6to4 destinations to your default router > rather than the local 6to4 pseudo interface. You clearly missed the point about the lower metric. Tony -------------------------------------------------------------------- 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 Mar 27 11:14:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJEfVV006600; Thu, 27 Mar 2003 11:14:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJEfl1006599; Thu, 27 Mar 2003 11:14:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJEbVV006592 for ; Thu, 27 Mar 2003 11:14:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJEjcU006502 for ; Thu, 27 Mar 2003 11:14:46 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26080 for ; Thu, 27 Mar 2003 12:14:38 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:14:33 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:14:33 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:14:33 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:14:32 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2RJELq20810; Thu, 27 Mar 2003 21:14:21 +0200 Date: Thu, 27 Mar 2003 21:14:21 +0200 (EET) From: Pekka Savola To: Tony Hain cc: "'Mika Liljeberg'" , "'Michel Py'" , "'Brian Carpenter'" , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] In-Reply-To: <054801c2f493$b581d5b0$ee1a4104@eagleswings> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 27 Mar 2003, Tony Hain wrote: > Mika Liljeberg wrote: > > On Thu, 2003-03-27 at 20:32, Tony Hain wrote: > > > Not necessarily. As long as the RA based prefix has a lower metric > > > than the local pseudo interface, there is no reason to disable it. > > > Depending on the implementation, this might allow for a faster > > > recovery when the RA disappears. > > > > Nope. If your network uses 6to4 addressing, you probably want > > to send off-link 6to4 destinations to your default router > > rather than the local 6to4 pseudo interface. > > You clearly missed the point about the lower metric. Note that "metric" is a bit vague term; it has significantly different implications whether it's applied before or after the longest-prefix-match. Ie. whether it is used as a sequential number in which to look for prefixes in different protocol-specific routing tables or to compare among different routes of the same prefix and length. In almost all cases, it's the latter. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 27 11:19:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJJbVV006799; Thu, 27 Mar 2003 11:19:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJJbqR006798; Thu, 27 Mar 2003 11:19:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJJYVV006791 for ; Thu, 27 Mar 2003 11:19:34 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJJgcU008396 for ; Thu, 27 Mar 2003 11:19:42 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21851 for ; Thu, 27 Mar 2003 11:19:36 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:19:35 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:19:35 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:19:35 Z Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:19:34 Z Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id A388A160B37; Thu, 27 Mar 2003 11:15:54 -0800 (PST) To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-reply-to: Mail from Brian E Carpenter dated Thu, 27 Mar 2003 18:46:04 +0100 <3E8338DC.495389E@hursley.ibm.com> Date: Thu, 27 Mar 2003 11:15:54 -0800 From: Naiming Shen Message-Id: <20030327191554.A388A160B37@prattle.redback.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ] Naiming Shen wrote: ] ... ] > though i'm absolutely against to have routing/dns ] > support to SL. ] ] SL's have to be routed within the site anyway, and probably have to be ] in local DNS to be of any use, which pretty much forces the use of two-faced ] DNS to avoid accidentally exporting them. ] ] In other words, the only sure way to avoid routing and DNS support for SLs ] is to abolish them. this assumes there will not be any need for private addresses in v6. otherwise, taking a random address block has the same issue. not only it needs two-faced DNS support, but also it could be leaked out in routing accidentally(people after use them for a while, will think its their legal address block; your peers will not automatically filter those announcements), people may randomly take microsoft.com's block and can't get their dirver updated anymore, etc. thus random block certainly is not better than a well known address block. but if this list is sure there is no need for private addresses, lets abolish them completely, not just from the special routing support sense. cheers. ] ] Brian ] -------------------------------------------------------------------- ] 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 ] -------------------------------------------------------------------- - Naiming -------------------------------------------------------------------- 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 Mar 27 11:38:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJcLVV007227; Thu, 27 Mar 2003 11:38:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJcLiW007226; Thu, 27 Mar 2003 11:38:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJcIVV007219 for ; Thu, 27 Mar 2003 11:38:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJcQcU015858 for ; Thu, 27 Mar 2003 11:38:26 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29591 for ; Thu, 27 Mar 2003 12:38:20 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:38:20 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:35:22 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:38:19 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:38:18 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2RJd4Vj021452; Thu, 27 Mar 2003 21:39:05 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2RJd0tE021451; Thu, 27 Mar 2003 21:39:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] From: Mika Liljeberg To: Pekka Savola Cc: Tony Hain , "'Michel Py'" , "'Brian Carpenter'" , ipng@sunroof.eng.sun.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048793939.21283.7.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 21:39:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-03-27 at 21:14, Pekka Savola wrote: > Note that "metric" is a bit vague term; it has significantly different > implications whether it's applied before or after the > longest-prefix-match. Ie. whether it is used as a sequential number in > which to look for prefixes in different protocol-specific routing tables > or to compare among different routes of the same prefix and length. > > In almost all cases, it's the latter. Exactly my point. If the pseudo interface has a 2002::/16 on-link route, longest prefix match will home in on it instead of the default route. I guess you could set the 6to4 pseudo-interface up with a (high metric) default route instead, in which case any other default route would take precedence and effectively disable the pseudo interface. MikaL -------------------------------------------------------------------- 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 Mar 27 11:43:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJhZVV007388; Thu, 27 Mar 2003 11:43:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJhZKm007387; Thu, 27 Mar 2003 11:43:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJhVVV007372 for ; Thu, 27 Mar 2003 11:43:31 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJhdHP009211 for ; Thu, 27 Mar 2003 11:43:39 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11103 for ; Thu, 27 Mar 2003 11:43:33 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:43:31 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:43:31 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:43:31 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:43:30 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Mar 2003 11:43:29 -0800 Reply-To: From: "Tony Hain" To: "'Mika Liljeberg'" , "'Pekka Savola'" Cc: "'Michel Py'" , "'Brian Carpenter'" , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Date: Thu, 27 Mar 2003 11:43:27 -0800 Message-Id: <055e01c2f499$2308ad20$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1048793939.21283.7.camel@devil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika Liljeberg wrote: > On Thu, 2003-03-27 at 21:14, Pekka Savola wrote: > > Note that "metric" is a bit vague term; it has > significantly different > > implications whether it's applied before or after the > > longest-prefix-match. Ie. whether it is used as a > sequential number > > in which to look for prefixes in different > protocol-specific routing > > tables or to compare among different routes of the same prefix and > > length. > > > > In almost all cases, it's the latter. > > Exactly my point. If the pseudo interface has a 2002::/16 > on-link route, longest prefix match will home in on it > instead of the default route. You are missing the point that your scenario has a 2002::/16 on-link route on the native interface as well. Default is not an issue here. Tony > > I guess you could set the 6to4 pseudo-interface up with a > (high metric) default route instead, in which case any other > default route would take precedence and effectively disable > the pseudo interface. > > MikaL > -------------------------------------------------------------------- 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 Mar 27 11:50:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJoHVV007632; Thu, 27 Mar 2003 11:50:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJoHeV007631; Thu, 27 Mar 2003 11:50:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJoEVV007624 for ; Thu, 27 Mar 2003 11:50:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJoMcU020558 for ; Thu, 27 Mar 2003 11:50:22 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24015 for ; Thu, 27 Mar 2003 12:50:17 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:50:16 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:50:16 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:50:15 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:50:15 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 27 Mar 2003 11:50:14 -0800 Reply-To: From: "Tony Hain" To: "'Naiming Shen'" , "'Brian E Carpenter'" Cc: Subject: RE: A use for site local addresses? Date: Thu, 27 Mar 2003 11:50:14 -0800 Message-Id: <055f01c2f49a$15e69890$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030327191554.A388A160B37@prattle.redback.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2RJoEVV007625 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Naiming Shen wrote: > ... > but if this list is sure there is no need for private > addresses, lets abolish them completely, not just from the > special routing support sense. The point is that those commenting against SL don't run a real network. There will be filtering done in real networks. This filtering creates addresses and/or prefixes with a local scope of applicability. IE: There will be local scope addresses in any case. The only question is if we have a well-known prefix that everyone filters on, or random values that require explicit n-way coordination. This also affects applications that might want to leverage the prior knowledge of the existence of such a filter. Tony -------------------------------------------------------------------- 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 Mar 27 11:53:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJr3VV007736; Thu, 27 Mar 2003 11:53:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJr3KW007735; Thu, 27 Mar 2003 11:53:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJqxVV007722 for ; Thu, 27 Mar 2003 11:52:59 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJr7HP012879 for ; Thu, 27 Mar 2003 11:53:07 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22176 for ; Thu, 27 Mar 2003 11:53:02 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:53:01 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:50:03 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:53:00 Z Received: from devil.pp.htv.fi ([62.78.149.57] [62.78.149.57]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:52:59 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) with ESMTP id h2RJrpVj021570; Thu, 27 Mar 2003 21:53:51 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.8/8.12.8/Debian-2) id h2RJroAP021569; Thu, 27 Mar 2003 21:53:50 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] From: Mika Liljeberg To: alh-ietf@tndh.net Cc: "'Pekka Savola'" , "'Michel Py'" , "'Brian Carpenter'" , ipng@sunroof.eng.sun.com In-Reply-To: <055e01c2f499$2308ad20$ee1a4104@eagleswings> References: <055e01c2f499$2308ad20$ee1a4104@eagleswings> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1048794830.21283.11.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 21:53:50 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-03-27 at 21:43, Tony Hain wrote: > > Exactly my point. If the pseudo interface has a 2002::/16 > > on-link route, longest prefix match will home in on it > > instead of the default route. > > You are missing the point that your scenario has a 2002::/16 on-link > route on the native interface as well. Default is not an issue here. Nope. It has a 2002:ab:cd:xy::/64 on-link route on the native interface. Any off-link 6to4 addresses will be routed to the pseudo interface. MikaL -------------------------------------------------------------------- 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 Mar 27 11:59:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJxAVV008157; Thu, 27 Mar 2003 11:59:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RJxANk008156; Thu, 27 Mar 2003 11:59:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RJx6VV008149 for ; Thu, 27 Mar 2003 11:59:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RJxEHP014927 for ; Thu, 27 Mar 2003 11:59:15 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18279 for ; Thu, 27 Mar 2003 12:59:07 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:58:32 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:58:32 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:58:31 Z Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 19:58:31 Z Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) with ESMTP id h2RJwOOc029267; Thu, 27 Mar 2003 21:58:24 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h2RJwNbZ029263; Thu, 27 Mar 2003 21:58:23 +0200 Date: Thu, 27 Mar 2003 21:58:23 +0200 Message-Id: <200303271958.h2RJwNbZ029263@burp.tkv.asdf.org> From: Markku Savela To: mika.liljeberg@welho.com CC: pekkas@netcore.fi, alh-ietf@tndh.net, michel@arneill-py.sacramento.ca.us, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: <1048793939.21283.7.camel@devil> (message from Mika Liljeberg on 27 Mar 2003 21:39:00 +0200) Subject: Re: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] References: <1048793939.21283.7.camel@devil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Mika Liljeberg > > Exactly my point. If the pseudo interface has a 2002::/16 on-link route, > longest prefix match will home in on it instead of the default route. Ahem, I need to step in here... a router is advertising 6to4 prefix, it will advertise it as (at least on ethernet): 2002:xxx::/64 L=1, A=0 or 1 thus, it's longer and metrics don't apply... (unless there there are two or more 6to4 prefixes announced). -------------------------------------------------------------------- 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 Mar 27 12:08:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RK81VV008560; Thu, 27 Mar 2003 12:08:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RK81K8008557; Thu, 27 Mar 2003 12:08:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RK7vVV008545 for ; Thu, 27 Mar 2003 12:07:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RK85HP018839 for ; Thu, 27 Mar 2003 12:08:05 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22718 for ; Thu, 27 Mar 2003 13:08:00 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:07:43 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:04:46 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:07:43 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:07:42 Z Received: from IDLEWYLDE.windriver.com ([147.11.46.223]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA22982; Thu, 27 Mar 2003 12:07:22 -0800 (PST) Message-Id: <5.1.0.14.2.20030327145957.03590958@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 27 Mar 2003 15:01:10 -0500 To: From: Margaret Wasserman Subject: RE: A use for site local addresses? Cc: In-Reply-To: <055f01c2f49a$15e69890$ee1a4104@eagleswings> References: <20030327191554.A388A160B37@prattle.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, >The point is that those commenting against SL don't run a real network. >There will be filtering done in real networks. This filtering creates >addresses and/or prefixes with a local scope of applicability. IE: There >will be local scope addresses in any case. The only question is if we >have a well-known prefix that everyone filters on, or random values that >require explicit n-way coordination. This also affects applications that >might want to leverage the prior knowledge of the existence of such a >filter. On the contrary, some of the pushback on site-local addressing has been from people who run real networks. One of the deciding factors in the WG meeting discussion was the statement from a few real network operators that they don't need a special prefix for non-connected networks -- since they'll have to renumber when they connect, anyway, they could just use a random prefix on their disconnected networks. There is only one reason why using a random prefix on disconnected IPv4 networks causes problems when those networks become globally connected -- NAT. Folks do not choose to renumber their networks, they use NAT instead. And, if they've chosen a random prefix, they won't be able to connect to outside networks that use that same prefix. We hope to avoid this problem in IPv6, by avoiding the use of NAT. If you accept that you will have to renumber when you move from a disconnected state to a globally connected state, why does it matter whether you used a well-known prefix or a random prefix before the renumbering? Margaret -------------------------------------------------------------------- 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 Mar 27 12:09:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RK9OVV008614; Thu, 27 Mar 2003 12:09:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RK9O9K008613; Thu, 27 Mar 2003 12:09:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RK9KVV008602 for ; Thu, 27 Mar 2003 12:09:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RK9ScU028786 for ; Thu, 27 Mar 2003 12:09:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23410 for ; Thu, 27 Mar 2003 13:09:22 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:09:20 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:09:20 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:09:20 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:09:20 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2RK9Bu21325; Thu, 27 Mar 2003 22:09:11 +0200 Date: Thu, 27 Mar 2003 22:09:11 +0200 (EET) From: Pekka Savola To: Mika Liljeberg cc: alh-ietf@tndh.net, "'Michel Py'" , "'Brian Carpenter'" , Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] In-Reply-To: <1048794830.21283.11.camel@devil> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 27 Mar 2003, Mika Liljeberg wrote: > On Thu, 2003-03-27 at 21:43, Tony Hain wrote: > > > Exactly my point. If the pseudo interface has a 2002::/16 > > > on-link route, longest prefix match will home in on it > > > instead of the default route. > > > > You are missing the point that your scenario has a 2002::/16 on-link > > route on the native interface as well. Default is not an issue here. > > Nope. It has a 2002:ab:cd:xy::/64 on-link route on the native interface. > Any off-link 6to4 addresses will be routed to the pseudo interface. .. unless it (must be a router, in practise) learns 2002::/16 from IGP, which is probably what Tony meant. This would be a horrible hack. It is typically not possible or recommended to be able to able to override the administrative "distance" (or "metric") of connected routes. You can work around this issue by advertising two /17's, though, to get the same effect. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 27 12:14:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKE0VV008849; Thu, 27 Mar 2003 12:14:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RKDxHj008843; Thu, 27 Mar 2003 12:13:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKDtVV008831 for ; Thu, 27 Mar 2003 12:13:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RKE3HP021197 for ; Thu, 27 Mar 2003 12:14:03 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05736 for ; Thu, 27 Mar 2003 12:13:58 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:53 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:53 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:52 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:52 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2RKDek21397; Thu, 27 Mar 2003 22:13:40 +0200 Date: Thu, 27 Mar 2003 22:13:39 +0200 (EET) From: Pekka Savola To: Tony Hain cc: "'Naiming Shen'" , "'Brian E Carpenter'" , Subject: RE: A use for site local addresses? In-Reply-To: <055f01c2f49a$15e69890$ee1a4104@eagleswings> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 27 Mar 2003, Tony Hain wrote: > Naiming Shen wrote: > > ... > > but if this list is sure there is no need for private > > addresses, lets abolish them completely, not just from the > > special routing support sense. > > The point is that those commenting against SL don't run a real network. I resent this statement. There were several speakers, which I believe, *do* run real networks. I think I do so too. > There will be filtering done in real networks. I don't think anyone disputes this. > This filtering creates > addresses and/or prefixes with a local scope of applicability. IE: There > will be local scope addresses in any case. But the real question is whether these local scope addresses need to be treated any different than the others. IMO, the obvious answer seems to be "no, why on earth??" > The only question is if we > have a well-known prefix that everyone filters on, or random values that > require explicit n-way coordination. N-way coordination is not necessary for the disconnected case. And when you connect, "default deny" at your ISP will block you from using your random block or if the ISP doesn't do it, your return packets will be routed to some unsuspecting guy and you'll change your addresses. I see no problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 27 12:14:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKEKVV008898; Thu, 27 Mar 2003 12:14:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RKEKg6008897; Thu, 27 Mar 2003 12:14:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKECVV008875 for ; Thu, 27 Mar 2003 12:14:13 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RKELcU001148 for ; Thu, 27 Mar 2003 12:14:21 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08955 for ; Thu, 27 Mar 2003 12:14:15 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:31 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:31 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:31 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:13:31 Z Content-class: urn:content-classes:message Subject: RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Mar 2003 12:13:30 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D32@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] Thread-Index: AcL0j4xQqULPeJZtQiiH+Rg9WGQpHwABnIgw From: "Michel Py" To: "Ole Troan" Cc: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2RKEDVV008876 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ole Troan wrote: > a host connected to a native link should not > automatically enable a 6to4 pseudo interface. Agree, and especially not if this native link RAses a prefix within 2002::/16. > Brian Carpenter wrote: > Some hosts can support such a pseudo-interface, but having > it on by default is a problem IMHO. > RFC 3056 mainly talks about routers and strongly implies > what Michel says, but that MUST NOT is not in any RFC. It should be, but is implied anyway because that's the only way it can work. Example: My IPv4 prefix is x.y.z.0/24 I have four subnets: - x.y.z.0/26 - x.y.z.64/26 - x.y.z.128/26 - x.y.z.192/26 My router is x.y.z.1 and x.y.z.65 and x.y.z.129 and x.y.z.193 host1 is x.y.z.66 host2 is x.y.z.67 I migrate to IPv6 using 6to4. I decide that my IPv6 prefix is 2002:xxyy:zz01::/48. Makes sense as the router is going to be the 6to4 gateway for the site. I will dual-stack. My subnets now are: Routing prefix|Site|IID |topo| - x.y.z.0/26 2002:xxyy:zz01:0000::/64 - x.y.z.64/26 2002:xxyy:zz01:0001::/64 - x.y.z.128/26 2002:xxyy:zz01:0002::/64 - x.y.z.192/26 2002:xxyy:zz01:0003::/64 | | My hosts IPv6 addresses should be: Routing prefix|Site|IID |topo| host1: 2002:xxyy:zz01:0001:HST1:I:I:D/64 host2: 2002:xxyy:zz01:0001:HST2:I:I:D/64 | | However, if there is a 6to4 interface enabled on the hosts, it breaks thinks as the hosts might decide to use: Routing prefix|Site|IID |topo| host1: 2002:xxyy:zz66:????:HST1:I:I:D/64 host2: 2002:xxyy:zz67:????:HST2:I:I:D/64 ^^| | || ?? Not only this is not what I want but it does break things as these two hosts are not even in the same IPv6 logical subnet with the 6to4 address they pick. If these two hosts need to talk together they need to transit by the router, no good. In other words: the fact that the RFC does not mention that hosts must not have a 6to4 pseudo-interface enabled if the link has a native prefix including those within 2002::/16 does not change the reality that 6to4 interfaces on hosts break things so using them is not an option unless there is only one host per site. Michel. -------------------------------------------------------------------- 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 Mar 27 12:53:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKrSVV009672; Thu, 27 Mar 2003 12:53:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RKrRBK009671; Thu, 27 Mar 2003 12:53:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKrOVV009664 for ; Thu, 27 Mar 2003 12:53:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RKrWHP005270 for ; Thu, 27 Mar 2003 12:53:32 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25456 for ; Thu, 27 Mar 2003 13:53:27 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:53:26 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:53:26 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:53:26 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:53:25 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2RKnPC14282; Thu, 27 Mar 2003 21:49:26 +0100 Message-Id: <3E8363D5.1010103@it.su.se> Date: Thu, 27 Mar 2003 21:49:25 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: Tony Hain , "'Naiming Shen'" , "'Brian E Carpenter'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: >On Thu, 27 Mar 2003, Tony Hain wrote: > > >>Naiming Shen wrote: >> >> >>>... >>>but if this list is sure there is no need for private >>>addresses, lets abolish them completely, not just from the >>>special routing support sense. >>> >>> >>The point is that those commenting against SL don't run a real network. >> >> > >I resent this statement. There were several speakers, which I believe, >*do* run real networks. I think I do so too. > > Yeah, me to. It sure feels real :-) but then maybe since I use global address on my 10k boxes I am not real enough... May I respectfully ask for some edification from those who do run real networks? Cheers Leif -------------------------------------------------------------------- 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 Mar 27 12:59:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKxUVV009805; Thu, 27 Mar 2003 12:59:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2RKxU2r009804; Thu, 27 Mar 2003 12:59:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2RKxQVV009791 for ; Thu, 27 Mar 2003 12:59:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2RKxYcU022058 for ; Thu, 27 Mar 2003 12:59:34 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12070 for ; Thu, 27 Mar 2003 12:59:28 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:59:06 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:58:38 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:58:37 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 27 Mar 2003 20:58:37 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2RKwZEO021210 for ; Thu, 27 Mar 2003 21:58:35 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2RKwYEx288076 for ; Thu, 27 Mar 2003 21:58:35 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44656 from ; Thu, 27 Mar 2003 21:58:33 +0100 Message-Id: <3E8365B6.CDE921AB@hursley.ibm.com> Date: Thu, 27 Mar 2003 21:57:26 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?] References: <1048793939.21283.7.camel@devil> <200303271958.h2RJwNbZ029263@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: > > > From: Mika Liljeberg > > > > Exactly my point. If the pseudo interface has a 2002::/16 on-link route, > > longest prefix match will home in on it instead of the default route. > > Ahem, I need to step in here... a router is advertising 6to4 prefix, > it will advertise it as (at least on ethernet): > > 2002:xxx::/64 L=1, A=0 or 1 > > thus, it's longer and metrics don't apply... (unless there there are > two or more 6to4 prefixes announced). Er, it's a /48, by definition. If it's a /64, that's already a subnet prefix within the /48 site prefix. Brian -------------------------------------------------------------------- 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 Mar 27 23:10:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2S7AiVV012031; Thu, 27 Mar 2003 23:10:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2S7Aip6012030; Thu, 27 Mar 2003 23:10:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2S7AfVV012023 for ; Thu, 27 Mar 2003 23:10:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2S7AncU017826 for ; Thu, 27 Mar 2003 23:10:49 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03021 for ; Fri, 28 Mar 2003 00:10:43 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 07:10:43 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 07:10:43 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 07:10:42 Z Received: from dhcp1.se.kurtis.pp.se ([192.71.80.74] [192.71.80.74]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 07:10:42 Z Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp1.se.kurtis.pp.se (8.12.7/8.10.2) with ESMTP id h2S77cWv001831; Fri, 28 Mar 2003 08:07:39 +0100 (CET) Date: Fri, 28 Mar 2003 07:52:31 +0100 Subject: Re: A use for site local addresses? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "David Conrad" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F50455EA@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> One of the downsides of site locals is the same downside >> you get with 1918 space -- merge two companies using private >> address space and you'll probably have to deal with address >> space collisions, forcing one of the two to renumber. > > There at least two drafts to make site-local addresses unique. > And at least one implementation - called unicast addressspace :-) - kurtis - -------------------------------------------------------------------- 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 Mar 28 02:52:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SAq1VV012601; Fri, 28 Mar 2003 02:52:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SAq0Co012600; Fri, 28 Mar 2003 02:52:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SApuVV012593 for ; Fri, 28 Mar 2003 02:51:57 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2SApmK00159; Fri, 28 Mar 2003 11:51:49 +0100 (MET) Date: Fri, 28 Mar 2003 09:29:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on the address selection API draft To: Mika Liljeberg Cc: Erik Nordmark , JINMEI Tatuya / =?UTF-8?Q?=E7=A5=9E=E6=98=8E=E9=81=94?= =?UTF-8?Q?=E5=93=89?= , Samita.Chakrabarti@eng.sun.com, Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <1048618512.12765.29.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The psychological benefit of the two flags is that we don't have to choose > > the default; we can say that any application which has an explicit preference > > should always invoke the API to state that preference. > > I don't follow. This is true regardless of whether there is one bit or > two. If an application doesn't care, it doesn't invoke the API at all. My point is that you have a socket option to say "FOO" it is very easy for app writers to assume that "FOO" isn't set by default; that is the case for all the existing socket options I can think of. But in this case the system admin is free to change the default. Thus how do we make this departure from existing practise clear to the app programmers? They need to turn off "FOO" is they don't want it since "FOO" might be the default set my the system admin. Having socket options that you use to set "FOO" or "NOTFOO" with no hard default I think makes the departure from existing practise more clear. 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 Fri Mar 28 02:52:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SAqEVV012611; Fri, 28 Mar 2003 02:52:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SAqE5x012610; Fri, 28 Mar 2003 02:52:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SAq7VV012603 for ; Fri, 28 Mar 2003 02:52:08 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2SAq4K00188; Fri, 28 Mar 2003 11:52:04 +0100 (MET) Date: Fri, 28 Mar 2003 09:52:02 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Draft on IPv6 source address selection socket API To: Francis Dupont Cc: Erik Nordmark , Samita Chakrabarti , Julien.Laganier@Sun.COM, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200303252012.h2PKCOof078802@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => this is like playing with UIDs, which are in the context of the > application and can be set by set[e]uid() & co, to permit or deny access to > privileged ports. My idea is to tune the context before performing some > operations and to reset it after to its previous setup. While the semantics of such an approach is well-documented and understood in the uid space, I think it is hard to introduce new such mechanisms due to the side effect dangers. Assume you introduce env/context source address selection knobs and that both getaddrinfo() and connect()/sendto() will use them. First problem that appears is that internal to getaddrinfo() sockets might be connected (e.g. to connect to a DNS server, LDAP, whatever else). It is hard to guage the possible impact of such side effects, but I think they in general make the system much harder to understand. (Yes, they are a form of global variables and I think passing explicit arguments results in less complexity that using global context.) 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 Fri Mar 28 03:11:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SBBMVV013025; Fri, 28 Mar 2003 03:11:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SBBLSd013024; Fri, 28 Mar 2003 03:11:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SBBIVV013017 for ; Fri, 28 Mar 2003 03:11:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SBBQHP020713 for ; Fri, 28 Mar 2003 03:11:26 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26417 for ; Fri, 28 Mar 2003 03:11:20 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 11:11:19 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 11:08:20 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 11:11:18 Z Received: from c001.snv.cp.net ([209.228.32.135] [209.228.32.135]) by relay12.sun.com for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 11:11:18 Z Received: (cpmta 17554 invoked from network); 28 Mar 2003 03:11:15 -0800 Received: from 139.92.208.233 (HELO w2knerick) by smtp.register-admin.com (209.228.32.135) with SMTP; 28 Mar 2003 03:11:15 -0800 X-Sent: 28 Mar 2003 11:11:15 GMT Message-Id: <001e01c2f51a$f53dfb70$e9d05c8b@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> <005101c2f433$b41e28a0$67061eac@ttitelecom.com> <3E8336DB.FB6A478D@hursley.ibm.com> Subject: Re: dual stack [Re: A use for site local addresses?] Date: Fri, 28 Mar 2003 14:12:40 +0300 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 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > EricLKlein wrote: > ... > > Our final decision > > was that we can not convert our database to pure IPv6 and let the hardware > > translate for us, so we will have to do it in the appliaction. > > Of course. Full dual stack support is the only rational starting point; > all the other coexistence mechanisms are second best. > But how close to a database (fro example) can the application vendor require a dual stack. I can not see the OSS/NMS/BSS vendor requiring that their customer must run Cisco router IOS 12.1 or higher. Therefore the application needs to have some minimal dual intelligence built in. Or this is how I see it, and thus the people speaking out against the local addresses are right it means more work for them rather than the customers running it. And this is as it should be. -------------------------------------------------------------------- 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 Mar 28 05:18:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SDIRVV013631; Fri, 28 Mar 2003 05:18:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SDIRMD013630; Fri, 28 Mar 2003 05:18:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SDINVV013623 for ; Fri, 28 Mar 2003 05:18:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SDIVHP017218 for ; Fri, 28 Mar 2003 05:18:31 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09218 for ; Fri, 28 Mar 2003 06:18:24 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 13:18:23 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 13:18:23 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 13:18:23 Z Received: from p-mail2 ([193.49.124.32] [193.49.124.32]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 13:18:22 Z Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail2 with InterScan Messaging Security Suite; Fri, 28 Mar 2003 14:23:25 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Mar 2003 14:18:05 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: A use for site local addresses? Date: Fri, 28 Mar 2003 14:18:04 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcL0nLalaT2LBKnOQ5u4qVu1GR7tDAAjFDlA From: "BAUDOT Alain FTRD/DMI/CAE" To: "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 28 Mar 2003 13:18:05.0218 (UTC) FILETIME=[77822820:01C2F52C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2SDIOVV013624 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > On the contrary, some of the pushback on site-local addressing > has been from people who run real networks. One of the deciding > factors in the WG meeting discussion was the statement from a few > real network operators that they don't need a special prefix for > non-connected networks -- since they'll have to renumber when they > connect, anyway, they could just use a random prefix on their > disconnected networks. > I actually don't understand why renumbering would be necessary while movingfrom disconnect to connect state. Do you make the assumption that only a single address must be used ? I think one may need/want to use both site-local addresses (for local traffic exactly the same way than during disconnect state) and global addresses (for external connections) together with address selection. In that case there is no need for NAT boxes, although that maybe used anyway. Then, renumbering will happen only when changing of ISP. On an other hand, site-local provides a global non-routable address space, that may be very usefull for adressing nodes (e.g. an ISP back-bone) that definitly do not need to be address from the outside. Alain. -------------------------------------------------------------------- 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 Mar 28 06:01:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SE1hVV014072; Fri, 28 Mar 2003 06:01:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SE1h9d014071; Fri, 28 Mar 2003 06:01:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SE1dVV014064 for ; Fri, 28 Mar 2003 06:01:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SE1lHP024984 for ; Fri, 28 Mar 2003 06:01:47 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28086 for ; Fri, 28 Mar 2003 07:01:39 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 14:01:38 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 14:01:37 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 14:01:37 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 14:01:34 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5B29E89E5; Fri, 28 Mar 2003 15:01:27 +0100 (CET) Received: from limbo (hobbes.ics.hro.nl [145.24.239.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 371E389E2; Fri, 28 Mar 2003 15:01:22 +0100 (CET) From: "Jeroen Massar" To: "'BAUDOT Alain FTRD/DMI/CAE'" Cc: Subject: RE: A use for site local addresses? Date: Fri, 28 Mar 2003 15:02:26 +0100 Organization: Unfix Message-Id: <006301c2f532$aa94e5d0$2eef1891@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2SE1dVV014065 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk BAUDOT Alain FTRD/DMI/CAE wrote: > Hi Margaret, > > > On the contrary, some of the pushback on site-local addressing > > has been from people who run real networks. One of the deciding > > factors in the WG meeting discussion was the statement from a few > > real network operators that they don't need a special prefix for > > non-connected networks -- since they'll have to renumber when they > > connect, anyway, they could just use a random prefix on their > > disconnected networks. > > > I actually don't understand why renumbering would be necessary while > movingfrom disconnect to connect state. Do you make the assumption > that only a single address must be used ? Because fec0:: (Site-local) would be used by many sites and is not routable? or do you mean that the site actually runs with a /48 from it's upstream, disconnects temporarily and then reconnects while retaining the same space? > I think one may need/want to use both site-local addresses (for local > traffic exactly the same way than during disconnect state) and global > addresses (for external connections) together with address selection. > In that case there is no need for NAT boxes, although that maybe used > anyway. Then, renumbering will happen only when changing of ISP. How is your application going to differentiate between site-local... oh wait, the application is going to need to differentiate to some address space in some cases but not all and clearly totally undefined. And you don't want to go even near NAT. Otherwise you will have to fix up all those protocols which carry IP addresses inside them. One of the major contenders: H323. If you imply NAT I think one can better stay at IPv4 where you don't have end-to-end communications either. Which was the reason otherwise that there are 128bits in the addresses? > On an other hand, site-local provides a global non-routable address > space, that may be very usefull for adressing nodes (e.g. an ISP back-bone) > that definitly do not need to be address from the outside. If you are an ISP you have a TLA with loads of /64's. Use those and apply some firewalling & non-routing to create *globally unique* non-routable address space. So if you merge/connect on day you won't have to renumber. Same goes for non-TLA holders, nobody claimed that the assigned space should also be routed. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 28 07:04:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SF4sVV014480; Fri, 28 Mar 2003 07:04:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SF4sH0014479; Fri, 28 Mar 2003 07:04:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SF4pVV014472 for ; Fri, 28 Mar 2003 07:04:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SF4wcU003465 for ; Fri, 28 Mar 2003 07:04:58 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16374 for ; Fri, 28 Mar 2003 08:04:52 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:04:51 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:04:51 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:04:51 Z Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by relay1.sun.com for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:04:50 Z Received: from parsmtp1.rd.francetelecom.com ([10.193.117.128]) by p-mail1 with InterScan Messaging Security Suite; Fri, 28 Mar 2003 16:05:07 +0100 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 28 Mar 2003 16:04:42 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: A use for site local addresses? Date: Fri, 28 Mar 2003 16:04:41 +0100 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcL1MpBQoMrGKhduTuaM7YPMiXVNqwAAkAXw From: "BAUDOT Alain FTRD/DMI/CAE" To: "Jeroen Massar" Cc: X-OriginalArrivalTime: 28 Mar 2003 15:04:42.0796 (UTC) FILETIME=[5CC316C0:01C2F53B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2SF4pVV014473 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jeroen, > > BAUDOT Alain FTRD/DMI/CAE wrote: > > > Hi Margaret, > > > > > On the contrary, some of the pushback on site-local addressing > > > has been from people who run real networks. One of the deciding > > > factors in the WG meeting discussion was the statement from a few > > > real network operators that they don't need a special prefix for > > > non-connected networks -- since they'll have to renumber when they > > > connect, anyway, they could just use a random prefix on their > > > disconnected networks. > > > > > > I actually don't understand why renumbering would be > necessary while > > movingfrom disconnect to connect state. Do you make the assumption > > that only a single address must be used ? > > Because fec0:: (Site-local) would be used by many sites and > is not routable? or do you mean that the site actually runs > with a /48 from it's upstream, disconnects temporarily and > then reconnects while retaining the same space? I mean site local has a local scope, so why renumering to global scope and not just leave as it is, and then having global, site-local and link-local addresses ? This actually refers to the moderate model. Unless using a single address for everything is for some reasons preferable. > > > I think one may need/want to use both site-local addresses > (for local > > traffic exactly the same way than during disconnect state) > and global > > addresses (for external connections) together with address > selection. > > In that case there is no need for NAT boxes, although that > maybe used > > anyway. Then, renumbering will happen only when changing of ISP. > > How is your application going to differentiate between > site-local... oh wait, the application is going to need > to differentiate to some address space in some cases but > not all and clearly totally undefined. And you don't want > to go even near NAT. Otherwise you will have to fix up > all those protocols which carry IP addresses inside them. > One of the major contenders: H323. The application will select local scope for local destination (e.g. Intranet) and global scope for destination having global addresses. Indeed H.323 applications most propably will have a global scope, and so, must use global addresses. > > If you imply NAT I think one can better stay at IPv4 where > you don't have end-to-end communications either. Which > was the reason otherwise that there are 128bits in the addresses? The idea is to avoid any use of NAT (that I definitly do NOT like), while using the capabilty of multiple adresses per intreface, IPv6 offers. One frequent benefit expected from private addressing (I agree it is more or less true) is related to use of non routing space, that is supposed to provide some security means. Since IPv4 enable to use only one address per interface, NAT becommes necessary for external communication. This limitation does not exist with IPv6, and just want benefit from it, that's all. One may imagine anenterprise network, for exemple, having nodes of local scope only (e.g. Intranetserver) and nodes needing both local and global > > > On an other hand, site-local provides a global non-routable address > > space, that may be very usefull for adressing nodes (e.g. an ISP > back-bone) > > that definitly do not need to be address from the outside. > > If you are an ISP you have a TLA with loads of /64's. > Use those and apply some firewalling & non-routing to > create *globally unique* non-routable address space. > So if you merge/connect on day you won't have to renumber. > Sure, it is possible this way. But a globally non-routing space preventing any undesirable packet coming from the whole Internet, sounds much better. Regards, Alain. -------------------------------------------------------------------- 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 Mar 28 07:14:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFEvVV014675; Fri, 28 Mar 2003 07:14:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SFEvMY014674; Fri, 28 Mar 2003 07:14:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFErVV014665 for ; Fri, 28 Mar 2003 07:14:53 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SFF1cU005932 for ; Fri, 28 Mar 2003 07:15:01 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25939 for ; Fri, 28 Mar 2003 07:14:55 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:14:55 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:14:55 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:14:55 Z Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:14:54 Z Received: from repligate ([67.36.180.12]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030328151454.TTYU11905.mailhost.chi1.ameritech.net@repligate> for ; Fri, 28 Mar 2003 09:14:54 -0600 Message-Id: <134a01c2f53c$dbc74df0$8500a8c0@repligate> From: "Jim Fleming" To: References: Subject: "The idea is to avoid any use of NAT..." ? Date: Fri, 28 Mar 2003 09:15:24 -0600 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "BAUDOT Alain FTRD/DMI/CAE" > > The idea is to avoid any use of NAT (that I definitly do NOT like), ==== The **consensus** of the free and open marketplace (especially in North, South, East and West America) is to use various transition mechanisms commonly called NAT, ICS, IPv8, etc. which are all based on the premise that that the 160-bit packet header has many unused bits which are available for expansion. Now that the Americas have been **liberated** from the * society regime, the InterNAT is taking shape. 128-bit DNS AAAA Record Flag Day Formats 2003:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("AM/FM") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt IPv8 0QQQQGGGSSSSSSSS[32-bits][Port] IPv16 0QQQQGGGSSSSSSSS[32-bits][Port] 1AAAAAAAAAAAAAAA[32-bits][Port] A...A=ASN=32769...65535 Jim Fleming http://www.IPv8.info -------------------------------------------------------------------- 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 Mar 28 07:17:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFH2VV014732; Fri, 28 Mar 2003 07:17:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SFH2aN014729; Fri, 28 Mar 2003 07:17:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFGwVV014721 for ; Fri, 28 Mar 2003 07:16:58 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SFH5HP011695 for ; Fri, 28 Mar 2003 07:17:05 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25270 for ; Fri, 28 Mar 2003 07:17:00 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:16:59 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:14:00 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:16:59 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:16:58 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h2SFGpdk097856; Fri, 28 Mar 2003 16:16:52 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2SFGnsi212292; Fri, 28 Mar 2003 16:16:50 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA56470 from ; Fri, 28 Mar 2003 16:16:42 +0100 Message-Id: <3E846718.62F218E@hursley.ibm.com> Date: Fri, 28 Mar 2003 16:15:36 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jeroen Massar Cc: "'BAUDOT Alain FTRD/DMI/CAE'" , ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think you're missing Alain's point. If a host happens to have 2 addresses at a given moment, one left over from the disconnected state and one with the recently available connected prefix, either address will work fine for internal usage, and of course only the second one will work for external usage. This does lead to DDNS and 2 face DNS, but that's where we are heading in any case. Brian Jeroen Massar wrote: > > BAUDOT Alain FTRD/DMI/CAE wrote: > > > Hi Margaret, > > > > > On the contrary, some of the pushback on site-local addressing > > > has been from people who run real networks. One of the deciding > > > factors in the WG meeting discussion was the statement from a few > > > real network operators that they don't need a special prefix for > > > non-connected networks -- since they'll have to renumber when they > > > connect, anyway, they could just use a random prefix on their > > > disconnected networks. > > > > > > I actually don't understand why renumbering would be necessary while > > movingfrom disconnect to connect state. Do you make the assumption > > that only a single address must be used ? > > Because fec0:: (Site-local) would be used by many sites and > is not routable? or do you mean that the site actually runs > with a /48 from it's upstream, disconnects temporarily and > then reconnects while retaining the same space? > > > I think one may need/want to use both site-local addresses (for local > > traffic exactly the same way than during disconnect state) and global > > addresses (for external connections) together with address selection. > > In that case there is no need for NAT boxes, although that maybe used > > anyway. Then, renumbering will happen only when changing of ISP. > > How is your application going to differentiate between > site-local... oh wait, the application is going to need > to differentiate to some address space in some cases but > not all and clearly totally undefined. And you don't want > to go even near NAT. Otherwise you will have to fix up > all those protocols which carry IP addresses inside them. > One of the major contenders: H323. > > If you imply NAT I think one can better stay at IPv4 where > you don't have end-to-end communications either. Which > was the reason otherwise that there are 128bits in the addresses? > > > On an other hand, site-local provides a global non-routable address > > space, that may be very usefull for adressing nodes (e.g. an ISP > back-bone) > > that definitly do not need to be address from the outside. > > If you are an ISP you have a TLA with loads of /64's. > Use those and apply some firewalling & non-routing to > create *globally unique* non-routable address space. > So if you merge/connect on day you won't have to renumber. > > Same goes for non-TLA holders, nobody claimed that > the assigned space should also be routed. > > > > Greets, > Jeroen > > -------------------------------------------------------------------- > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- 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 Mar 28 07:25:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFP9VV015140; Fri, 28 Mar 2003 07:25:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SFP84G015139; Fri, 28 Mar 2003 07:25:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFP5VV015130 for ; Fri, 28 Mar 2003 07:25:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SFPCHP013972 for ; Fri, 28 Mar 2003 07:25:12 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10143 for ; Fri, 28 Mar 2003 08:25:06 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:24:59 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:24:58 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:24:58 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:24:58 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id D443189FE; Fri, 28 Mar 2003 16:24:54 +0100 (CET) Received: from limbo (hobbes.ics.hro.nl [145.24.239.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 37BAC7E25; Fri, 28 Mar 2003 16:24:48 +0100 (CET) From: "Jeroen Massar" To: "'Brian E Carpenter'" Cc: "'BAUDOT Alain FTRD/DMI/CAE'" , Subject: RE: A use for site local addresses? Date: Fri, 28 Mar 2003 16:25:52 +0100 Organization: Unfix Message-Id: <007d01c2f53e$53539800$2eef1891@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <3E846718.62F218E@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2SFP5VV015133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter [mailto:brian@hursley.ibm.com] wrote: > I think you're missing Alain's point. If a host happens to > have 2 addresses at a given moment, one left over from the > disconnected state and one with the recently available > connected prefix, either address will work fine for > internal usage, and of course only the second one will work > for external usage. > > This does lead to DDNS and 2 face DNS, but that's where we are heading > in any case. That's indeed a different approach than what I had in mind. And does indeed work as long as the 'disconnected prefix' should never be mixed with another network ofcourse. Thanks for the clarification. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 28 07:25:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFPkVV015202; Fri, 28 Mar 2003 07:25:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SFPkVm015201; Fri, 28 Mar 2003 07:25:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFPgVV015191 for ; Fri, 28 Mar 2003 07:25:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SFPocU008825 for ; Fri, 28 Mar 2003 07:25:50 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29637 for ; Fri, 28 Mar 2003 08:25:43 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:25:43 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:25:42 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:25:42 Z Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:25:41 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2SFPdSo058084 for ; Fri, 28 Mar 2003 16:25:39 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2SFPasi287622 for ; Fri, 28 Mar 2003 16:25:37 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17880 from ; Fri, 28 Mar 2003 16:25:33 +0100 Message-Id: <3E84692A.AB45C878@hursley.ibm.com> Date: Fri, 28 Mar 2003 16:24:26 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: dual stack [Re: A use for site local addresses?] References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> <005101c2f433$b41e28a0$67061eac@ttitelecom.com> <3E8336DB.FB6A478D@hursley.ibm.com> <001e01c2f51a$f53dfb70$e9d05c8b@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > > > EricLKlein wrote: > > ... > > > Our final decision > > > was that we can not convert our database to pure IPv6 and let the > hardware > > > translate for us, so we will have to do it in the appliaction. > > > > Of course. Full dual stack support is the only rational starting point; > > all the other coexistence mechanisms are second best. > > > But how close to a database (fro example) can the application vendor require > a dual stack. > > I can not see the OSS/NMS/BSS vendor requiring that their customer must run > Cisco router IOS 12.1 or higher. Therefore the application needs to have > some minimal dual intelligence built in. That's why the basic dual stack mechanism includes tunnels - the server would need to establish a tunnel out to the nearest available IPv6 router. The application still sees the dual stack socket API. Brian -------------------------------------------------------------------- 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 Mar 28 07:40:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFe2VV015966; Fri, 28 Mar 2003 07:40:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SFe1RX015965; Fri, 28 Mar 2003 07:40:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFdvVV015952 for ; Fri, 28 Mar 2003 07:39:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SFe5cU012686 for ; Fri, 28 Mar 2003 07:40:05 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02009 for ; Fri, 28 Mar 2003 08:39:59 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:39:41 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:39:40 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:39:40 Z Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:39:40 Z Received: from repligate ([67.36.180.12]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030328153938.UCMX11905.mailhost.chi1.ameritech.net@repligate> for ; Fri, 28 Mar 2003 09:39:38 -0600 Message-Id: <136c01c2f540$50673b90$8500a8c0@repligate> From: "Jim Fleming" To: References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> <005101c2f433$b41e28a0$67061eac@ttitelecom.com> <3E8336DB.FB6A478D@hursley.ibm.com> <001e01c2f51a$f53dfb70$e9d05c8b@ttitelecom.com> <3E84692A.AB45C878@hursley.ibm.com> Subject: DSTM, Tunnels, Performance, Reality, The Laws of Physics, etc. Date: Fri, 28 Mar 2003 09:40:08 -0600 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Brian E Carpenter" > > That's why the basic dual stack mechanism includes tunnels - the server would > need to establish a tunnel out to the nearest available IPv6 router. The application > still sees the dual stack socket API. > Tunnels are a non-starter because people are not going to move from a 160-bit header to a 320-bit basic header, followed by numerous other bloated headers and then add more headers just to tunnel across the legacy IPv4 32-bit Internet. The laws of physics can not be changed. You can only push bits so fast thru a particular medium. With the liberated American marketplace, free from the I* society regime, the focus is on SERVICES. Services are now being developed and deployed that assume minimal bandwidth requirements and efficient routing. IPv16 only allows native mode, there is no tunnel mode. Not only that, the data rides inside of the IPv6 basic header in the unused bloated address bits. The 320-bit header is the packet, the only packet, for many services. Jim Fleming http://www.IPv8.info -------------------------------------------------------------------- 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 Mar 28 07:45:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFjbVV016203; Fri, 28 Mar 2003 07:45:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SFjbhw016202; Fri, 28 Mar 2003 07:45:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFjXVV016192 for ; Fri, 28 Mar 2003 07:45:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SFjfcU014034 for ; Fri, 28 Mar 2003 07:45:41 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15253 for ; Fri, 28 Mar 2003 08:45:35 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:45:35 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:42:36 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:45:35 Z Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:45:35 Z Received: from repligate ([67.36.180.12]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030328154534.UEOV11905.mailhost.chi1.ameritech.net@repligate> for ; Fri, 28 Mar 2003 09:45:34 -0600 Message-Id: <137801c2f541$24d148d0$8500a8c0@repligate> From: "Jim Fleming" To: References: <963621801C6D3E4A9CF454A1972AE8F54D22@server2000.arneill-py.sacramento.ca.us> <005101c2f433$b41e28a0$67061eac@ttitelecom.com> <3E8336DB.FB6A478D@hursley.ibm.com> <001e01c2f51a$f53dfb70$e9d05c8b@ttitelecom.com> <3E84692A.AB45C878@hursley.ibm.com> Subject: States to Legislate Against IPv6 ? Date: Fri, 28 Mar 2003 09:46:05 -0600 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.theinquirer.net/?article=8595 "the various states bills all require the banning the use of any technology that conceals "the existence or place of origin or destination of any communication." ===== -------------------------------------------------------------------- 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 Mar 28 07:58:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFwrVV016552; Fri, 28 Mar 2003 07:58:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SFwrx1016551; Fri, 28 Mar 2003 07:58:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SFwnVV016544 for ; Fri, 28 Mar 2003 07:58:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SFwvHP022983 for ; Fri, 28 Mar 2003 07:58:57 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27588 for ; Fri, 28 Mar 2003 08:58:49 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:58:42 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:55:29 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:58:28 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 15:58:27 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 438AA8A02; Fri, 28 Mar 2003 16:58:24 +0100 (CET) Received: from limbo (hobbes.ics.hro.nl [145.24.239.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5E8FB8376; Fri, 28 Mar 2003 16:58:18 +0100 (CET) From: "Jeroen Massar" To: "'BAUDOT Alain FTRD/DMI/CAE'" Cc: Subject: RE: A use for site local addresses? Date: Fri, 28 Mar 2003 16:59:22 +0100 Organization: Unfix Message-Id: <008f01c2f543$00a54400$2eef1891@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2SFwnVV016545 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk BAUDOT Alain FTRD/DMI/CAE wrote: > > BAUDOT Alain FTRD/DMI/CAE wrote: > > > I actually don't understand why renumbering would be > > > necessary while movingfrom disconnect to connect state. > > > Do you make the assumption that only a single address must be used ? > > > > Because fec0:: (Site-local) would be used by many sites and > > is not routable? or do you mean that the site actually runs > > with a /48 from it's upstream, disconnects temporarily and > > then reconnects while retaining the same space? > > I mean site local has a local scope, so why renumering to global scope > and not just leave as it is, and then having global, site-local and > link-local addresses ? This actually refers to the moderate model. > Unless using a single address for everything is for some reasons > preferable. But how is a application going to know which prefix to chose? Is it going to do this based on the destination prefix? Is this going to happen in the application or by the stack? Onlink is easy fe80::/10 and you need to specify scope to make it work anyways. But how about sitelocal in this case? > > > I think one may need/want to use both site-local addresses > > (for local > > > traffic exactly the same way than during disconnect state) > > and global > > > addresses (for external connections) together with address > > selection. > > > In that case there is no need for NAT boxes, although that > > maybe used > > > anyway. Then, renumbering will happen only when changing of ISP. > > > > How is your application going to differentiate between > > site-local... oh wait, the application is going to need > > to differentiate to some address space in some cases but > > not all and clearly totally undefined. And you don't want > > to go even near NAT. Otherwise you will have to fix up > > all those protocols which carry IP addresses inside them. > > One of the major contenders: H323. > > The application will select local scope for local destination (e.g. > Intranet) and global scope for destination having global addresses. > Indeed H.323 applications most propably will have a global scope, > and so, must use global addresses. On most routing platforms it's possible to set a loopback IP. Thus specifying that per default that IP should be used as an 'outgoing' address. Are you suggesting to have 2 of these? One for site and one for global scope? Thus if a destination prefix matches sitelocal scope that it uses the sitelocal IP? > > If you imply NAT I think one can better stay at IPv4 where > > you don't have end-to-end communications either. Which > > was the reason otherwise that there are 128bits in the addresses? > > The idea is to avoid any use of NAT (that I definitly do NOT like), > while using the capabilty of multiple adresses per intreface, > IPv6 offers. One frequent benefit expected from private > addressing (I agree it is more or less true) is related to > use of non routing space, that is supposed to provide some > security means. Some evil BOFH's and probably some others before them invented nullroutes for that purpose :) And ofcourse firewalling. I don't think anybody should ever relate Site Local to secure. If some $company gets the idea that Site Locals are 'secure' then all of a sudden their boxes will show with 'Uses site local thus is secure' which is, like you say yourself not true ofcourse. > Since IPv4 enable to use only one address per interface, > NAT becommes necessary for external communication. Even a NT4 box sports multiple IP's per interface. Linux kernels sport so called aliases and most if not all other OS's will have similar features (Keeping Win9x out of the equation). > This limitation does not exist with IPv6, and just want > benefit from it, that's all. There is a problem with multiple addresses in the 'which outgoing address to choose' case. Especially when a good ISP refuses to route any packets with a source which is not on that interface (RPF). > One may imagine anenterprise network, for exemple, having > nodes of local scope only (e.g. Intranetserver) and nodes > needing both local and global local on link or local in site? eg: www.intranet.example.com 2001:db8:222::80 (2001:db8:222::/48 is 'private') www.internet.example.com 2001:db8:444::80 (2001:db8:444::/48 is 'global') If a host only has one address it will simply use that. If a host has multiple ones it will match the destination address and use that as an outgoing address. I even think that this is currently already the case with most stacks. Only thing to 'worry' about is when you have multiple addresses like above. > > > On an other hand, site-local provides a global non-routable address > > > space, that may be very usefull for adressing nodes (e.g. an ISP > > back-bone) that definitly do not need to be address from the outside. > > > > If you are an ISP you have a TLA with loads of /64's. > > Use those and apply some firewalling & non-routing to > > create *globally unique* non-routable address space. > > So if you merge/connect on day you won't have to renumber. > > > Sure, it is possible this way. But a globally non-routing space > preventing any undesirable packet coming from the whole Internet, > sounds much better. If one really really wants a seperate block which should never be seen anywhere on the public internet then at least make it possible to uniquely register this space in some way. This will avoid many of the problems which will arise when two 'private' networks merge as they are globally unique. If people can't be educated to maintain&update their software/firewalls etc there is little use IMHO. Just take a look at all the complaints about 69/8... And not even talking about that 3ffe:1f00::/24 ghost route that wandered in the IPv6 routing tables without anybody complaing about it, nor responding to enquiries. But the invisible forces that be made sure that it vanished after exactly a month. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 28 13:05:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SL5XVV018014; Fri, 28 Mar 2003 13:05:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SL5Xl9018013; Fri, 28 Mar 2003 13:05:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SL5TVV018006 for ; Fri, 28 Mar 2003 13:05:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SL5bHP009187 for ; Fri, 28 Mar 2003 13:05:37 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06478 for ; Fri, 28 Mar 2003 14:05:31 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:05:30 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:05:30 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:05:29 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:05:30 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA08059; Fri, 28 Mar 2003 13:05:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2SL5Rr17188; Fri, 28 Mar 2003 13:05:27 -0800 X-mProtect: <200303282105> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.151, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsnQmqh; Fri, 28 Mar 2003 13:05:22 PST Message-Id: <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Mar 2003 13:05:19 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft IPv6 Minutes from Atlanta IETF Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_619156810==_" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_619156810==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Draft IPv6 working group minutes from the San Francisco IETF are attached. Please review and send comments. Thanks, Bob --=====================_619156810==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="ipv6-wg-minutes-mar2003.txt" IPv6 Working Group (ipv6) Agenda IETF 56, San Francisco CHAIRS: Bob Hinden Margaret Wasserman Minutes notes taken: Bob Fink (March 17, 2003) Christian Huitema (March 20, 2003) AGENDA: Introduction and Agenda Bashing -- Bob Hinden (5 min) Updated Charter -- Bob Hinden (10 min) Working Group Action Plan -- Margaret Wasserman (15 min) Prefix Delegation: - Prefix Delegation Requirements -- Shin Miyakawa (10 min) - DHCP Option for Prefix Delegation -- Ole Troan (5 min) - Moving forward on Proxy RA Approach -- Bob Hinden (5 min) IPv6 MIBs -- Margaret Wasserman (10 min) IPv6 Addressing Architecture Appeal: - Overview of IAB Response -- Leslie Daigle (20 min) - Working Group Response to Appeal Process -- Margaret Wasserman (10 min) Access Control Prefix RA Option -- Steve Bellovin (10 min) IPv6 Node Requirements, Open Issues -- John Loughney (30 min) Analysis of IPv6 Anycast -- Itojun Hagino (10 min) DHCPv6 DNS Resolver Configuration Option -- Ralph Droms (10 min) IPv6 over Fibre Channel Review Request -- Claudio DeSanti (5 min) IPv6 Addressing Architecture - Review of IAB Recommendations & Next Steps -- Margaret Wasserman (30 min) Node-Requirements follow up (10 min) Site-Local Addressing -- Bob Hinden and Margaret Wasserman (60 min) IPv6 Socket API for source address selection -- Erik Nordmark (10 min) ================================================= First Session: Monday, March 17, 2003, 1930-2200 ================================================= Introduction and Agenda Bashing -- Bob Hinden --------------------------------------------- Bob opened the meeting and reviewed the agenda. There were no changes to the published agenda. Updated Charter -- Bob Hinden ----------------------------- As discussed in Atlanta, except: DNS Discovery removed from the charter ADs instructed chairs to remove work item (an explanation sent to working group mailing list) topic will be discussed at DNSOP session Goal for end of year is to either re-charter or close wg. Primary wg responsibilities are: Completing work on the IPv6 working group documents Reviewing and updating IPv6 specifications based on implementation and deployment experience, and advancing them on the standardization track as appropriate. Hinden presented a list of urgent work items and a list of current work. Action Plan -- Margaret Wasserman --------------------------------- Margaret Wasserman presented document status and related actions. Bob Hinden thanked the authors of flow label draft. Itojun asked what the status of the anycast analysis draft is. Margaret said not clear if it was part of the work of the wg yet. Need to decide. Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa ------------------------------------------------------------------ Shin Miyakawa presented his work on prefix delegation requirements. Shin noted that he appreciated the Michel Py and Pekka Savola comments. Shin outlined them to see if there was agreement with going ahead with the draft with Pekka's changes or not. Michel Py said he was willing to go with the current text without changes for his comments. Margaret asked what the wg thought of the changes. Brian Haberman said layer two work out of scope. On lifetime he thinks it should cascade down. The wg agreed. Margaret asked how many people thought PPP be included, or should this layer two stuff be removed. Christian thinks there is a difference between a serial link and a shared link. So don't have to say PPP, but must note the difference. Dave Thaler thinks PPP and CHAP stuff should go away. Needs to be a mechanism that works on a shared link. Also prioritization should be removed. Margaret asked if PPP and CHAP should be removed: unanimous to remove. Margaret asked if the Layer 2 auth should be removed: unanimous generic layer 2 auth stuff to stay. Sentiment expressed there be a requirement for a solution that works on a shared link. Jordi Palet stated that it needs a shared link solution. Hesham Soliman asked why this was more complex? Shin said PPoE employed as it is easy to identify customer equipment. Francis Dupont agreed with PPoE, but need a shared link solution. Margaret asked if we need a prefix delegation solution on shared link: consensus was that we need a solution that does. Shin will modify the draft and get out for further review as soon as possible. DHCP Option for Prefix Delegation -- Ole Troan ---------------------------------------------- Ole presented his DHCP option for prefix delegation. He felt that it was ready for wg last call. There were no comments. Moving forward on Proxy RA Approach -- Bob Hinden ------------------------------------------------- Bob talked on Proxy RA solution. If progress, we need to have volunteers to work on draft to extract appropriate text from the multilink subnet stuff. Dave Thaler volunteered to work on this, but needs comments from folks that it meets requirements. Ole thinks it my be useful but that it doesn't meet all requirements. Christian happy that Dave will do the job, and wants to excise the proxy RA stuff from the multilink subnet draft, but there are problems with home users stacking routers at home. So there is a need for multilink subnet solution. Dave expressed concern as to what people think RA proxy means as there are different thoughts on this. Need input/comments to help. No further comment. Presumably Dave Thaler will proceed to work on this solution. IPv6 MIBs: Forwarding, TCP & UDP MIBs Open Issues -- Margaret Wasserman ----------------------------------------------------------------------- Margaret presented a status report on various IPv6 MIB efforts. There were few folk that have read this or that have any comments. Margaret extolled folk to review and help forwarding these drafts. Dave Thaler noted that he had read the TCP MIB and believes it is ready for wg last call. Generally there was agreement that these MIBs are needed, but very few have read them and have an opinion on technical content. Margaret noted that the UDP MIB needs an editor. Someone asked if the OPS area have reviewed them. Margaret said they have not and probably won't until forwarded. Margaret may mention these to the OPS area at their meeting this week. Dave Thaler outlined problem with the forwarding MIB. There is a problem with interpretation of TOS byte. Brian Carpenter said he would review and help resolve this. IP MIB Open Issues -- Shawn Routhier ------------------------------------ There was no presentation. Incorporated in previous talk. IPv6 Addressing Architecture Appeal ----------------------------------- Overview of IAB Response -- Leslie Daigle ----------------------------------------- Leslie presented a clarification of the IAB response to the Robert Elz appeal in the IPv6 Addressing Architecture as there was some apparent confusion of what the IAB was saying. It does not say this draft should not be forwarded. Nor does it give directive to the wg. It does say this draft is not clear enough for a DS, and clarity needed to ensure interoperable implementations. Not challenging the IPv6 architecture. A future version may go to DS. Some things are recommended to be fixed. Not treading on IESG space. All further discussion to be in wg. There were no comments. Working Group Response to Appeal Process -- Margaret Wasserman -------------------------------------------------------------- Margaret noted what further discussion on this topic would happen on Thursday, specifically on how to respond to the comments, and then on what to do with the draft. Margaret asked wg folk to review the available information in preparation for Thursday's meeting. There were no comments. Access Control Prefix RA Option -- Steve Bellovin ------------------------------------------------- http://www.ietf.org/internet-drafts/draft-bellovin-ipv6-accessprefix-01.txt Steve presented on his access control prefix RA option draft. Christian said the conclusion slide that this is not a security solution is why Brian Zill's solution wanted to keep the mechanism simple. Keith Moore asked if we want to build in network topology and addressing coincidence. He felt there were similar problem with this approach as with site-local, which Keith does not like. Perry Metzger said this proposal demonstrated we should get rid of site-local. Dave Thaler noted access control mechanism has similar problem to Brian's choice. Steve agreed. Tony Hain noticed this is not really different than site-local. Margaret disagreed and noted that there could be different prefixes with Steve's approach. Pekka Savola felt there are differences in Steve's approach and site-local. Dave Thaler agreed with Tony. Would prefer a change to the node rules. Christian had similar comments. Margaret noted that this is part of the greater site-local discussion to take place later in the week (when Steve won't be available). There was no further discussion as this will be revisited at Thursday's meeting. IPv6 Node Requirements, Open Issues -- John Loughney ---------------------------------------------------- John presented his open issues with his current version of IPv6 node requirements. --- Hesham Soliman asked about the DHCP support rewording re SHOULD or MAY. Doesn't consider it to be useful. Doesn't need to be a SHOULD. Dave Thaler asked Ralph Droms if there is still an interest in DHCP on this? Jim Bound felt stateful configuration is a MUST. M bit must be set. Node can ignore. Customers that have stateful environments will not go to stateless environments. Christian disagreed. No question that we must support stateless. Market will take care of this. MAY is enough. Rob Austein said that John should separate question on this. Bob Hinden, speaking personally, noted that he would not want to see people have to implement functionality they don't need. Perry Metzger felt that it doesn't matter which we choose as we are being precise about how to be imprecise. John wanted to know how to resolve. Bob Hinden asked who wanted to keep the existing text (says MAY). In looking at the text to see if this was the way to frame the question John decided it was best to send a proposed change to the list so it could be discussed Thursday. --- On privacy extensions for addr conf, Alain Durand said there are reverse path dns issues when a random address may not resolve. Keith said it is more general, and need an API for this. Pekka asked if this is actually used. John said probably good to have the code, but use can cause a problem so should be aware of that. If per node basis things will break it should be done on a per API basis. Seemed to be consensus to go with John's suggested text change. --- Mobile IP - Routers SHOULD support the requirements set for all IPv6 routers. Several comments that this doesn't sound right. Should be changed to routers SHOULD support mobile IP requirements. --- Security - still questions. What level of security to document. Gave example. Steve Belovin noted trying to get rid of DES. Thus should remove the MUST. John will ask someone in security to review this. Margaret noted that she liked the idea of separating security into a separate draft. Steve Belovin wanted to take this off line. John wants to hold off on the security section. He will edit the other items and ask if it is ready for last call, barring the way security is reviewed and/or changed. Bob Hinden wants to defer the security issue as IPSEC isn't useful in every device, e.g., a device that might want SSL or SSH for security, and doesn't want IPSEC. So need to think about this broadly, thus should go ahead without security for now to make progress. Jim Bound said that if we want to revisit MUST that it is an IPSEC job. Where do we stop if we do this. IPSEC is a MUST historically and IP6 is the front line of defense for security by using IPSEC to secure the IP level. Thomas concerned about a node requirements doc with no security. Need a lot of help from security group to have a serious discussion on this. John likes having a reference to a doc with current best current security practices for IPSEC. Keith doesn't like having IPSEC as it isn't really a solution. Jim Bound said we could make a more specific by node type document rather than this general approach. To alter the existing MUST/SHOULD with this doc is bad idea as it would be in conflict. Jim said he could do a review on MUSTS to see if anything should be changed. Keith felt that this specification should be for generic programmable nodes. Maybe other specific, i.e., fixed function, devices should not be covered by this. Margaret disagreed and noted that were many many of these types of devices to consider. Bob felt that the intro should note the scope re Keith's comment. John will pose issues about stateful addresses and M & O bits, as well as more discussion on security. Agreed that the wg needs to decide how to handle security. Analysis of IPv6 Anycast -- Itojun Hagino ----------------------------------------- Itojun presented a short status report on his analysis of IPv6 anycast. He has received some comments from Erik and he will generate a new version but doesn't know if it should require a last call. Margaret wanted to redo the w.g. last call this new draft as it has been a long time since it was last reviewed. =================================================== Second Session: Thursday, March 20, 2003, 0900-1130 =================================================== Bob Hinden presents the agenda. 60 minutes are left for the discussion of the site local addressing issue. Noted that original agenda items for site-local are changed. Now there will be a singe presentation jointly presented by both chairs. DHCPv6 DNS Resolver Configuration Option -- Ralph Droms ------------------------------------------------------- Ralph Droms presents the state of DNS configuration in DHCPv6. There are two DHCP options: DNS server and Domain search list. The DNS server option has been adopted by the DHCP group, after some searching of the proper option name, which turns out to be "recursive name server"; another issue was whether to carry IPv4 addresses as well as IPv6, which was resolved by only carrying IPv6 addresses. The Domain search list option is exactly copied from the similar DHCPv4 option. The two options have passed DHCP WG last call. DHCPv6 is now a proposed standard, in the RFC editor queue; implementations have been tested at TAHI connecthaton. Work is ongoing on a stateless DHCPv6 subset, which allows for a lightweight implementation. The stateless DHCPv6 draft needs review from implementers, to make sure that it is written in a "developer friendly" way. Dave Thaler asks what the resolution is for the search path option, and possible differences between a value returned over IPv6 and another received over IPv4? Ralph answers that this will be left to the host. Pekka Savola observes that there is the same issue with the DNS server list; but for Ralph this is not a really issue. Rob Austein: the choice of server is who you ask, but all are supposed to return the same answer; the search string is what you ask, which changes the answer. Alain Durand retorts that change in the calling order of servers can affect the response delays, so some precision is important to avoid operational problems. In any case, says Ralph, this is not really a DHCPv6 issue: DHC specifies a configuration mechanism; choosing the order of responses is a management option. The drafts will be updated to include a short discussion of this point. For Keith Moore, the search list mechanism is broken anyhow, and should not be used at all, so fixing it is irrelevant. Alain Durand points out the analogy with the choice of routers by hosts, which is indeed left to the host. IPv6 over Fibre Channel Review Request -- Claudio DeSanti --------------------------------------------------------- Claudio Desanti presents the work on IPv6 over Fiber Channel. FC is a Storage Area Network. There is an IPv4 specification already, but we need an IPv6 specification. IPv4 over FC defines its own ARP mechanism, but for IPv6 they want to leverage Neighbor Discovery. FC channel nodes have their own 64 bit identifier, but routing is based on volatile 24 bits labels; an upper layer protocol manages a sequence of frames. Work in ANSI T11 committee has defined how to map FC name identifiers into EUI 64 format. The draft defines how to generate a node identifier, how to map link local Unicast and Multicast, and how to map the channel and exchange management. The question to the IPv6 WG is what to do with the spec: either an "IPv6 over FOO" work item in the IPv6 WG, or an individual submission progressing to PS after IPv6 WG review. Margaret points out that IPv6 over FOO is not in our charter anymore, so the second option will have to be discussed with the AD. Pekka Savola observes that the draft is very hard to read by someone not versed in FC. Thomas Narten agrees with Margaret that the only role of the IPv6 WG should only be tasked to provide a review. Greg Carlson, as Thomas, mentions that the responsibility of the work should be in the TLC working group. IPv6 Addressing Architecture- Review of IAB Recommendations & Next Steps -- Margaret Wasserman ------------------------------------------------------------------------ Margaret Wasserman presents the IPv6 WG response to the IAB recommendations on Robert Elz appeal. The IAB response at several sections, one presenting their conclusion, and another presenting their recommendations. The recommendations are informative in nature, but they cannot be ignored. The questions to answer are: is 64 bit a hard boundary; what is the exact meaning of global scope, and what to do with the U bit. Margaret engages in a review of each of these issues. Is 64 bit a hard boundary? It is quite clear that all formats except those with a 000 bit prefix have a hard 64 bit boundary. Review of the text found a reference to CIDR that might be construed to envisage aggregation of prefixes longer than 64 bits; this will have to be fixed. Pekka Savola does not need it needs clarification; rather, we should revise the whole concept, because otherwise some implementations will stop prefix matching at 64 bits, which is in his mind broken. Thomas Narten restates the IAB requirement: was there an already made architecture decision on the 64 bits split , or is it left for further discussion; for example, should applications be required to enable routing on a /124? Margaret mentions that the only discussion is for the 0::/3 prefix. Bob Hinden mentions that the application only have to do CIDR on the first 64 bits. The current specification of the 0::/3 prefix is longest match to arbitrary length. We agree that the section is not clear, and will have to be edited. Erik Nordmark mentions that the spirit of the document is clear, the implementation requirement is not, and there is still discussion in the operator community, e.g. allow /127 bit prefix on PPP links. Jim Bound mentions that it is a well known fact that we should not restrict prefix match to 64 bits. Thomas asks whether this is actually the consensus of the group? Michel Py finds that the text is clear, so asks what exactly is confusing about it? Margaret answers that if the IAB cannot understand it there is an issue. Fred Templin mentions that there may be some need in the future to match more bits than 64. Hashim mentions that there is a prefix length in the RA options; how does the 64 decision affect RA processing? Keith Moore advocates that we do not repeat the class-full address assignment mistake of IPv4; he suggests that we keep a requirement for routers to match arbitrary length tables. The issue with global scope was a confusion between global scope and global uniqueness; it assumes that any address with the U bit set is globally unique. The proposal is to refer to the U bit as "universal", and to reserve use of the adjective "global" for global scope addresses. Erik Nordmark mentions that there is no requirement to consider the U bit in routing processing. Fred Templin agrees with Margaret. Keith Moore mentions that we should explicitly warn applications to make no assumption about the structure of the address. The interoperability requirements of the U bit were unclear; the appeal pointed out that we did not show two implementations that tested the U bit in an interoperable way. For Margaret, this is really a documentation issue: implementations are not required to allocate any meaning to the U bit and test its uniqueness; the U bit is only used as a way to construct host identifiers. Bob Hinden believes that changing the text to not require any test will remove the interoperability issue. Keith Moore goes one further: applications should not assume that an identifier with the U bit set is globally unique. This is pretty clear already, says Margaret. Obviously, there is wide consensus in the room. The IAB had 5 recommendations: publish the document at PS, which has been approved; update the document to include clear and concise interoperability requirement using RFC 2026 and 2119 language, which is agreed with the WG with two reservations regarding the U bit (see above) and the 2119 language; update the requirement for 64 bit identifiers, which we discussed previously; and that we revise the ND and auto-configuration specification to include the knowledge of the 64 bit boundary, which will be considered when we update these document at a later date. Margaret would like to thank the IAB for reviewing our document and helping us make it stronger. IPv6 Node Requirements, Follow Up -- John Loughney -------------------------------------------------- John Loughney provides a quick update on the nodes requirement draft. The big open issue was the state of the "stateful address auto-configuration" requirement. The agreement on the mailing list is to have this rated as "MAY support", for which John proposes a text; there is also a requirement that if the WG eventually chooses to say that application "SHOULD" support, there should be a strong qualifier authorizing implementations to opt out. A show of hands shows 59 hands up for preferring MAY, 21 for SHOULD; the chairs believe that this constitute rough consensus in the room, but we need to verify the decision on the mailing list. Another update on the requirement draft is the state of requirement of support for DHCPv6: must support if use for stateful address autoconfiguration; should support for other configuration; may support if no stateful or other configuration is needed. Christian Huitema asks for clarification, whether the "other configuration" really means "stateless DHCP". Thomas Narten asks whether we are making the explicit decision that DHCPv6 is "THE" stateful address configuration mechanism? John concludes that this specific paragraph needs further discussion on the mailing list. Ralph asks for clarification of the handling of the M bit and the O bit. Site-Local Usage Discussion -- Margaret Wasserman & Bob Hinden -------------------------------------------------------------- Margaret Wasserman opens the IPv6 site local discussion. Presentation done in round robin fashion by both chairs. Goals for discussion: analyze options, reach consensus on approach. It is important for WG to make a decision (don't want endless debate) chairs will support whatever achieves consensus. There are several choices: get rid of site local altogether; limit their use to disconnected sites; create an exclusion requirement so nodes cannot configure both site local and global addresses; a prohibition of nodes belonging to several sites; and full usage. There are documentation for the "limited", "moderate" and "full" options; the "exclusive" model is undocumented; there is WG consensus to not support the "full" option, and as a consequence the progress of the current scoped address architecture draft is frozen. The limited model implies only using site locals in disconnected sites, and requires renumbering when the site becomes connected. Margaret's slide mention usage behind an IPv6 NAT; Keith Moore objects that this is a license for NAT; Margaret agrees that the limited model could imply the use of IPv6-IPv6 NAT. The exclusive model mentions that nodes will never be configured with both site local and global addresses. This simplifies address selection a lot, but requires some form of host configuration. The exclusivity limits the potential for leakage. Brian Carpenter asks what happens when a site is oscillating between connected and disconnected; Bob Hinden answers that in the exclusive state, the globally addresses nodes will simply become unreachable when the site is disconnected. Alain Durand asks for clarification. Thomas suggests that this would become a router advertisement restriction, but this becomes hard to enforce when there are several routers on a link. Margaret restates the intention: even if hosts receive advertisements for both type of prefixes, a host configuration bit will govern which type of address gets configured. Alain Durand observes that if there is no enforcement mechanism, this exclusion requirement is totally useless. Jim Chang states something that the note taker could not understand. Michel Py suggests that we should make global and site local exclusive on a given subnet. Thomas wonders whether there are open issues in this proposal, and this is hard to assess in the absence of a formal document. Keith Moore wonders how that applies to hosts with multiple interfaces, which seems unwieldy. Marc Blanchet asks whether the requirement applies to routers? Answer: Yes. Erik Nordmark wonders whether a single link would have a site local printer and another global scope host; the answer is yes. Pekka Savola mentions that if nodes also mention routers, then we should say so explicitly, as it has wide consequences on routing. The moderate model allows for site local addresses if they are explicitly configured. Nodes can have both type of address. A site border router will be in exactly one site, with some interfaces in no site at all. We will have to revise the address selection algorithms to not prefer site local, and revise a couple of other documents as well. The benefit of the limited model is that it allows addressing for disconnected sites. Christian Huitema pointed out that Margaret's references to IPv6<->IPv6 NAT were divisive and unnecessary, and said that Margaret was trying to link the limited model to IPv6 NAT. Margaret said that the limited model could be used behind IPv6 NAT or NAT-PT, but did not require the use of either type of NAT. Margaret agreed that the topic of IPv6 NAT was divisive and agreed that, in retrospect, it would have been better not to include it on the slides. For Margaret, the exclusive model has the additional benefit that it allows stable addressing for local nodes. Bernard Thuy observes that this discussion never took multicast into account; what is the impact? Brian Carpenter points out that the limited model has a benefit not carried in the other model, i.e. simplifies the handling of addresses by applications. Alain Durand challenges the stated benefit of the exclusive model: nodes that have global addresses will have to oscillate between the two types of addresses. The moderate model has additional benefits: it allows stable addressing, and easy communication. The issue list included: IP layer address leaking; IP address selection issues; DNS address leaking; address leaking by other layers; handling of boundaries in routing protocols; forwarding table issues; and mobile IP issues. IP layer address leaking is addressed by all proposal. Limited and exclusive do not require changes to address selection rules; moderate requires switching the order of preference. Exclusive and moderate need enforcement mechanism to avoid leaking in the DNS. Limited does not have a leakage problem in applications, since there is no connectivity; exclusive probably eliminates the issue as well; moderate requires upper layers to incorporate some address selection rules. All proposals eliminate the routing protocol issues, as well as the forwarding table issues, as no proposal allows a router to be in more than one site at the same time. The limited proposal eliminates the possibility to support mobility out of the site; exclusive and moderate requires mobile nodes to use global addresses. As a summary, limited eliminates most problems, but it also eliminates all the benefits. Exclusive does not have the issue of requiring handling of scoped addresses in applications. Bob think it important that the working group gets consensus on the issue. Margaret tries to impress the need that we have to reach a decision today: choose between the 4 options, or possibly excise the site locals from the scope address document, and just consider global and site locals. Pekka Savola believes that the exclusive option as presented is broken; it is only usable in limited cases, e.g. placing a few local nodes in an otherwise global link; the only reason is to restrict access to nodes, which can be node by the less intrusive access prefix option. Alain Durand believes that the analysis of address leakage is wrong: we have an implementation of that model with RFC 1918 today, and addresses do leak; Margaret believes that this is due to implementation mistakes, which raises some heckles; Alain believes that the only way to avoid the issue is not use site locals at all. Keith Moore believes that IPv6 will not be useful as long as we don't support site local; reserving the site local addresses to disconnected sites will not work, as proven by the RFC 1918 experience. Matt Mathis wants to reinforce Keith's point: looking work at the early ways of the ROAD WG, having applications consider the scope of addresses was already consider a bad idea then, and is still a bad idea now; we should not require applications to know anything about the scope of addresses. Brian Haberman believes that any analysis of the issues is bound to be incomplete, and would support an option to just excise the site local addresses from the scoped address architecture; as an editor of the scoped address document, Brian proposes to just do that. Fred Templin believes that site locals will benefit intermittently connected sites. Michel Py supports the exclusive model as a way to move forward, if it is enforced on the entire link. Erik is concerned that we don't have enough information to decide yet, because we don't have consensus on requirements; for example, the requirement to renumber without breaking connections triggers lots of complexity for mobile nodes; the requirement of a security boundaries can be solved in other ways; disconnected sites should be able to use global addresses in most cases; and we don't have to make it easy to implement NATs. Christian Huitema suggests that the exclusive model is an illusion; it is not documented yet, and the devil is in the details; it is also not enforceable, as nodes who want both addresses just have to pretend that they have two link local addresses. Hesham Soliman agrees with Christian that the exclusive model is a charade. Rob Austein agrees with Erik Nordmark and Christian Huitema; thanks the chair for pointing out that all solutions solve the IP issue, and that only the limited model solves the application issue. Leif Johansson points out the very strong requirement that applications don't have to care with address scope. Dino Farinacci points out that a disconnected site can in fact use any prefix, his disconnected site uses 2001::/16; he does not need that we need site local addressing. Mohsen Feci wonders whether we really need site local addresses; IPv6 addresses are not rare; not having site local addresses to solve the problem. Kurtis Lindqvist points out that all proposal force the network to maintain some state; that the site local costs us more than it brings. Someone points out that the main benefit of IPv6 is global addresses; we can just use global addresses. Samita adds her voice to the idea of elimination of site local. Christian Huitema will prefer eliminating site local over adopting the "limited" option. Thomas Narten wonders whether the consensus in the room is for shifting towards eliminating site local. Bob and Margaret have a private conversation where they discuss how to proceed to measure w.g. consensus. Keith Moore would like to make an offer; observes that we cannot eliminate the site local, but that we should actively study alternatives for their various proposed use. He suggest that we write a document that deprecates the usage of site-local addresses and includes in that document ways of obtaining the features of site-local addresses using global IPv6 addresses. Marc Blanchet is afraid that if we forget about site local now, they will be invented back later. Dave Thaler mentions the zerouter BOF, which needs a recommendation for how to automatically configure a disconnected network. For Erik Nordmark, if we eliminate site local, we have to remove the currently existing code that handles FEC0::/10. Brian Carpenter comments that RFC 1597 was one of the worse end runs in the history of the IETF, and that interaction with NAT is clearly out of our control; however, he would prefer to deprecate these addresses. Fred Templin believes that we will still need a solution for intermittently disconnected sites; this problem should be addressed. Jim Bound points out that IPv4 NAT is a national security problem, and that an attempt to control them are misguided. Keith Moore repeats the requirement that applications should not be concerned with the scope of addresses. Margaret asks the question, do we want to deprecate site local addresses? There are 20 hands up for not deprecating, 102 hands up for deprecating; This is interpreted as rough consensus to deprecate site local addressing; this consensus will have to be verified on the mailing list. IPv6 Socket API for source address selection -- Erik Nordmark ------------------------------------------------------------- [No time for this talk] ------------------------------------------------------------------ ------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------ ------------------------------------------------------------------ --=====================_619156810==_-- -------------------------------------------------------------------- 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 Mar 28 13:07:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SL7bVV018068; Fri, 28 Mar 2003 13:07:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2SL7bxR018066; Fri, 28 Mar 2003 13:07:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2SL7XVV018057 for ; Fri, 28 Mar 2003 13:07:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2SL7fHP009781 for ; Fri, 28 Mar 2003 13:07:41 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10259 for ; Fri, 28 Mar 2003 14:07:36 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:07:34 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:07:33 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:07:33 Z Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 28 Mar 2003 21:07:34 Z Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA08112; Fri, 28 Mar 2003 13:07:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2SL7Vo17889; Fri, 28 Mar 2003 13:07:31 -0800 X-mProtect: <200303282107> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.151, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5CCXge; Fri, 28 Mar 2003 13:07:30 PST Message-Id: <4.3.2.7.2.20030328130556.0309fdf8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Mar 2003 13:07:27 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: Draft IPv6 Minutes from Atlanta IETF In-Reply-To: <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, the subject should have been "Draft IPv6 Minutes from the San Francisco IETF". The minutes are OK. Bob At 01:05 PM 3/28/2003, Bob Hinden wrote: >Draft IPv6 working group minutes from the San Francisco IETF are attached. > >Please review and send comments. > >Thanks, >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 Fri Mar 28 16:43:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2T0hSVV019122; Fri, 28 Mar 2003 16:43:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2T0hSdJ019121; Fri, 28 Mar 2003 16:43:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2T0hPVV019114 for ; Fri, 28 Mar 2003 16:43:25 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2T0hWcU017666 for ; Fri, 28 Mar 2003 16:43:33 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01161 for ; Fri, 28 Mar 2003 16:43:27 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 00:43:26 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 00:43:26 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 00:43:26 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 00:43:26 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 28 Mar 2003 16:43:23 -0800 Reply-To: From: "Tony Hain" To: "'Bob Hinden'" , Subject: RE: Draft IPv6 Minutes from Atlanta IETF Date: Fri, 28 Mar 2003 16:43:23 -0800 Message-Id: <068d01c2f58c$341b8300$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2T0hPVV019115 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It is interesting that Erik pointed out there was not enough information to make a decision due to lack of agreement about the requirements, yet that was ignored and the decision was made to press on and call a question that was not even on the agenda ... >From the minutes, the characterizations I heard that the decision was based on fear of NAT appears to be correct as comments about it are liberally spread through the discussion. In particular they appear in the summary discussion right before the question. This subterfuge only furthers the lack of understanding about what site-local is. Local address space is a filtering function, and exists with or without header mangling. Filtering will exist in real network deployments, so having a space set aside for that purpose does not change the architectural reality. I agree that much of the group doesn't understand the requirements of the network managers, so I have started a draft on that subject. Granted this is an early pass, with content based primarily on previous email, but it does provide a basis for discussion. Comments requested: http://www.tndh.net/~tony/ietf/site-local.txt Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com] On Behalf Of Bob Hinden > Sent: Friday, March 28, 2003 1:05 PM > To: ipng@sunroof.eng.sun.com > Subject: Draft IPv6 Minutes from Atlanta IETF > > > Draft IPv6 working group minutes from the San Francisco IETF > are attached. > > Please review and send comments. > > Thanks, > 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 Fri Mar 28 17:11:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2T1B8VV019381; Fri, 28 Mar 2003 17:11:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2T1B8Ix019380; Fri, 28 Mar 2003 17:11:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2T1B4VV019373 for ; Fri, 28 Mar 2003 17:11:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2T1BCHP026077 for ; Fri, 28 Mar 2003 17:11:12 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18070 for ; Fri, 28 Mar 2003 17:11:06 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:11:06 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:10:47 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:10:47 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:10:46 Z Received: from cisco.com (sjc-vpn3-586.cisco.com [10.21.66.74]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA28039; Fri, 28 Mar 2003 17:10:43 -0800 (PST) Message-Id: <3E84F292.60606@cisco.com> Date: Fri, 28 Mar 2003 17:10:42 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft IPv6 Minutes from Atlanta IETF References: <068d01c2f58c$341b8300$ee1a4104@eagleswings> In-Reply-To: <068d01c2f58c$341b8300$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually the filtering you mention in the draft set was thought of at the time of RFC 1597. The result was that it set back ISP security years if not decades. ISPs needed a default deny with explicit permit model whereas site-locals and their predecessors allow for a lazy default permit policy. While RPF is useful and good, better is a default-deny model. Eliot -------------------------------------------------------------------- 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 Mar 28 17:18:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2T1I0VV019540; Fri, 28 Mar 2003 17:18:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2T1I0Nq019539; Fri, 28 Mar 2003 17:18:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2T1HvVV019532 for ; Fri, 28 Mar 2003 17:17:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2T1I4cU028096 for ; Fri, 28 Mar 2003 17:18:04 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04269 for ; Fri, 28 Mar 2003 18:17:59 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:17:58 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:14:58 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:17:58 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 01:17:58 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 28 Mar 2003 17:17:56 -0800 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" Cc: "'Bob Hinden'" , Subject: RE: Draft IPv6 Minutes from Atlanta IETF Date: Fri, 28 Mar 2003 17:17:56 -0800 Message-Id: <068f01c2f591$076b70e0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E84F292.60606@cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2T1HvVV019533 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: > While RPF is useful and good, better is a > default-deny model. Those are orthogonal concepts. Route filtering is about limiting the ability to return traffic to a site, while RPF is about enforcing that a site is sourcing traffic from a valid prefix. Both are required. Tony -------------------------------------------------------------------- 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 Mar 29 04:21:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2TCLrVV021416; Sat, 29 Mar 2003 04:21:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2TCLrpT021415; Sat, 29 Mar 2003 04:21:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2TCLnVV021408; Sat, 29 Mar 2003 04:21:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2TCLsHP020440; Sat, 29 Mar 2003 04:21:54 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07007; Sat, 29 Mar 2003 05:21:49 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP; Sat, 29 Mar 2003 12:21:48 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP; Sat, 29 Mar 2003 12:21:47 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP; Sat, 29 Mar 2003 12:21:47 Z Received: from consulintel.es ([213.172.48.142] [213.172.48.142]) by relay1.sun.com with ESMTP; Sat, 29 Mar 2003 12:21:47 Z Received: from consulintel02 ([217.126.187.160]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R); Sat, 29 Mar 2003 13:20:29 +0100 Message-Id: <00c801c2f5ed$e02dd6f0$870a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: "ipv6cluster List Member" , , , , , <6bone@ISI.EDU>, , Subject: next Madrid 2003 Global IPv6 Summit Date: Sat, 29 Mar 2003 13:22:18 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C2F5F6.38D04B50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C2F5F6.38D04B50 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, In case you still not noticed, the next major IPv6 Summit in Europe will = take place in Madrid (May 12-14th). This is the bigger European IPv6 = Forum event, and probably the bigger international one. You can't miss = it ! See http://www.ipv6-es.com; register now and take advantage of the early = registration offer. A lot of surprises will be discovered, including the Award Ceremony of = the IPv6 Appli-Contest 2003 (if you want to participate see = http://www.v6pc.jp/apc/en/index.html). Regards, Jordi Almost a hundred projects are demonstrating that IPv6 is working well. = The European Union=92s expectations regarding the new protocol, in order = to support its leadership as a future economic power, are becoming real. = The "Madrid 2003 Global IPv6 Summit" is the major European event of the = year where you can learn of the latest developments in IPv6 standards = and deployment.=20 For the third consecutive year we invite you to participate in this key = event about Internet developments. You have a unique opportunity to = discover more about the evolution of the Internet to deliver new = applications and services. ***************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Register at: http://www.ipv6-es.com ------=_NextPart_000_00C5_01C2F5F6.38D04B50 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,

In case you still not = noticed, the=20 next major IPv6 Summit in Europe will take place in Madrid (May = 12-14th). This=20 is the bigger European IPv6 Forum event, and probably the bigger = international=20 one. You can't miss it !

See http://www.ipv6-es.com; register now = and take=20 advantage of the early registration offer.
 
A lot of surprises will be discovered, = including=20 the Award Ceremony of the IPv6 Appli-Contest 2003 (if you want to = participate=20 see http://www.v6pc.jp/apc/en/i= ndex.html).

Regards,
Jordi


Almost a = hundred projects=20 are demonstrating that IPv6 is working well. The European Union=92s = expectations=20 regarding the new protocol, in order to support its leadership as a = future=20 economic power, are becoming real. The "Madrid 2003 Global IPv6 Summit" = is the=20 major European event of the year where you can learn of the latest = developments=20 in IPv6 standards and deployment.

For the third consecutive year = we=20 invite you to participate in this key event about Internet developments. = You=20 have a unique opportunity to discover more about the evolution of the = Internet=20 to deliver new applications and services.

*****************************
Madrid 2003 Global IPv6 Summit
12-14 May 2003 - Register at:
http://www.ipv6-es.com ------=_NextPart_000_00C5_01C2F5F6.38D04B50-- -------------------------------------------------------------------- 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 Mar 29 05:39:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2TDdcVV022283; Sat, 29 Mar 2003 05:39:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8/Submit) id h2TDdcpG022282; Sat, 29 Mar 2003 05:39:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.8+Sun/8.12.8) with ESMTP id h2TDdZVV022275 for ; Sat, 29 Mar 2003 05:39:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2TDdgHP001453 for ; Sat, 29 Mar 2003 05:39:42 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02998 for ; Sat, 29 Mar 2003 05:39:36 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 13:39:36 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 13:39:36 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 13:39:35 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 13:39:35 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA04128 for ; Sat, 29 Mar 2003 13:39:34 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA28191 for ; Sat, 29 Mar 2003 13:39:33 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2TDdXq07953 for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 13:39:33 GMT Date: Sat, 29 Mar 2003 13:39:33 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030329133933.GF7796@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> <3E846718.62F218E@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E846718.62F218E@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Mar 28, 2003 at 04:15:36PM +0100, Brian E Carpenter wrote: > I think you're missing Alain's point. If a host happens to have 2 addresses > at a given moment, one left over from the disconnected state and one with > the recently available connected prefix, either address will work fine for > internal usage, and of course only the second one will work for external usage. > > This does lead to DDNS and 2 face DNS, but that's where we are heading > in any case. So is it actually having a recommended prefix for disconnected networks that's the issue, or having special scope prrocessing for a specific prefix, or both? :) I think this is what Alain is indirectly asking/suggesting. 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 Sat Mar 29 14:18:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2TMINPL024189; Sat, 29 Mar 2003 14:18:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2TMIMpw024188; Sat, 29 Mar 2003 14:18:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2TMIJPL024181 for ; Sat, 29 Mar 2003 14:18:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2TMIJHP024378 for ; Sat, 29 Mar 2003 14:18:19 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12669 for ; Sat, 29 Mar 2003 15:18:13 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 22:18:13 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 22:18:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 22:18:12 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 22:18:11 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA06976 for ; Sat, 29 Mar 2003 22:18:09 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA12397 for ; Sat, 29 Mar 2003 22:18:09 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2TMI9B11944 for ipng@sunroof.eng.sun.com; Sat, 29 Mar 2003 22:18:09 GMT Date: Sat, 29 Mar 2003 22:18:09 +0000 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Draft IPv6 Minutes from Atlanta IETF Message-Id: <20030329221809.GB11625@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> <068d01c2f58c$341b8300$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <068d01c2f58c$341b8300$ee1a4104@eagleswings> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Mar 28, 2003 at 04:43:23PM -0800, Tony Hain wrote: > I agree that much of the group doesn't understand the requirements of > the network managers, so I have started a draft on that subject. Granted > this is an early pass, with content based primarily on previous email, > but it does provide a basis for discussion. Comments requested: > http://www.tndh.net/~tony/ietf/site-local.txt It's good that this subject is attracting an I-D. Perhaps we should first focus on "IPv6 address requirements for networks" from which we could judge the relative merits and failings of solutions that meet those requirements - address stability, surviving network disconnection, renumbering on (re-)connection, etc... for different classes of networks. Of course, a "Site Locals Considered Harmful" would also be useful (Keith, you know it makes sense, and less effort than 100 emails to the list :) If such opinion can be documented we may save a few hundred emails when Margaret puts out the call for list consensus (or maybe we won't...) 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 Sun Mar 30 06:28:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UESVPL026874; Sun, 30 Mar 2003 06:28:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2UESU2n026873; Sun, 30 Mar 2003 06:28:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UESRPL026866 for ; Sun, 30 Mar 2003 06:28:27 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2UESUcU015539 for ; Sun, 30 Mar 2003 06:28:31 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14904 for ; Sun, 30 Mar 2003 06:28:25 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:28:25 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:28:22 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:28:22 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:28:22 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA05372; Sun, 30 Mar 2003 06:27:58 -0800 (PST) Message-Id: <5.1.0.14.2.20030330090234.048d6590@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 30 Mar 2003 09:23:13 -0500 To: From: Margaret Wasserman Subject: RE: Draft IPv6 Minutes from Atlanta IETF Cc: "'Bob Hinden'" , In-Reply-To: <068d01c2f58c$341b8300$ee1a4104@eagleswings> References: <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:43 PM 3/28/2003 -0800, Tony Hain wrote: >It is interesting that Erik pointed out there was not enough information >to make a decision due to lack of agreement about the requirements, yet >that was ignored and the decision was made to press on and call a >question that was not even on the agenda ... Actually, Erik objected to calling the question to decide between the three site-local alternatives ("limited", "exclusive" or "moderate"). And, in fact, we never called that question... Discussion continued from that point, including further comments from Erik. It became clear that there was significant support within the group for deprecating site-local addressing altogether, so we decided to call a different questions -- whether or not to deprecate site-local addressing. There was some discussion regarding the meaning of that question, and people were given an opportunity to object to the phrasing/timing of the question (none did). I am sorry that you were ill and unable to attend the meeting and express your opinion. I also appreciate your consideration and concern for the health of others. But, I believe that you have a mistaken impression regarding what took place in the IPv6 meeting. As is true of most IETF minutes, these minutes do not really capture the discussion very well. I have heard that there are "movies" available for multicast sessions, so it is possible that you could get a better idea of what happened in the meeting by watching the movie. There were many people in the room who have traditionally supported site-local addressing, and about 20 people who stated their opinion that site-local addresses should not be deprecated. Those people have NOT been posting to the IETF list or the IPv6 list indicating that they feel that the process was used unfairly during the meeting, or that the results did not represent the consensus of the room. In fact, a few of them have written and said that they disagreed with the decision, but that they support the consensus of the WG. Please think about that. I also strongly object to your poor characterization of the IPv6 WG attendees. There were many people in the room who write "real" implementations and/or run "real" networks, and there were experts present from many different IETF areas that could be affected by site-local addressing (most notably routing, DNS, and applications). Margaret -------------------------------------------------------------------- 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 Mar 30 06:59:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UEx8PL027194; Sun, 30 Mar 2003 06:59:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2UEx8p0027193; Sun, 30 Mar 2003 06:59:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UEx4PL027186 for ; Sun, 30 Mar 2003 06:59:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2UExCHP010708 for ; Sun, 30 Mar 2003 06:59:12 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02670 for ; Sun, 30 Mar 2003 07:59:06 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:59:05 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:56:00 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:59:04 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 14:58:53 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA11960; Sun, 30 Mar 2003 06:57:58 -0800 (PST) Message-Id: <5.1.0.14.2.20030330092651.03674240@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 30 Mar 2003 09:47:44 -0500 To: Tim Chown From: Margaret Wasserman Subject: Re: Draft IPv6 Minutes from Atlanta IETF Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20030329221809.GB11625@login.ecs.soton.ac.uk> References: <068d01c2f58c$341b8300$ee1a4104@eagleswings> <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> <068d01c2f58c$341b8300$ee1a4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Of course, a "Site Locals Considered Harmful" would also be useful (Keith, >you >know it makes sense, and less effort than 100 emails to the list :) I agree that such a document would be useful. I doubt, though, that it will prevent 100's of e-mails to the list -- I've just become resigned to spending ~45 minutes a day reading e-mail on the IPv6 list... As part of deprecating site-local addressing, we agreed in the meeting that, in addition to deprecating site-local addressing in the addressing architecture and removing it from other places (scoped addressing architecture, address selection rules, etc.), a document would be written that would do two things: - Explain why site-local addressing was deprecated - Outline alternative means to address some of the problems that could have been solved by site-local addressing. A "site-locals considered harmful" document could be a part of this document or be referenced from it. One of the problems of writing such a document is that "site-locals" are a moving target. We have (at least) five different proposals on the table for site-local address "usage" (only four of which are documented), and most of those proposals can be modified by one or more of the proposals to create "unique" site-local addresses. I attempted to capture the issues associated with site-local addressing in my site-local impact draft: http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt This document specifically addresses the benefits and issues associated with the "full" site-local model currently documented in the scoped addressing architecture WG I-D. I did not consider other models, because at the time this document was written, the "full" model was the only documented model... A subset of these benefits and issues exists for each of the less complete site-local usage models. Bob and I attempted to capture, in our IPv6 WG presentation, the benefits and issues associated with each of the three usage models we presented -- "limited", "exclusive" and "moderate". We focused on the differences between those three approaches -- mainly whether or not they require split DNS and whether or not they require address selection logic in applications that pass addresses to other nodes. I don't believe that our presentation is on the minutes site yet, but it can be found at: http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt It might serve as useful input for a "considered harmful" document, or for an attempt to explain the decision to deprecate site locals. Margaret -------------------------------------------------------------------- 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 Mar 30 07:24:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UFOWPL027448; Sun, 30 Mar 2003 07:24:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2UFOWJh027447; Sun, 30 Mar 2003 07:24:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UFOTPL027440 for ; Sun, 30 Mar 2003 07:24:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2UFObcU025095 for ; Sun, 30 Mar 2003 07:24:37 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28904 for ; Sun, 30 Mar 2003 08:24:26 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 15:24:26 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 15:21:21 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 15:24:25 Z Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 15:24:24 Z Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) with ESMTP id h2UFOKOc027512; Sun, 30 Mar 2003 18:24:20 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian-5) id h2UFOKux027508; Sun, 30 Mar 2003 18:24:20 +0300 Date: Sun, 30 Mar 2003 18:24:20 +0300 Message-Id: <200303301524.h2UFOKux027508@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: tjc@ecs.soton.ac.uk, ipng@sunroof.eng.sun.com In-reply-to: <5.1.0.14.2.20030330092651.03674240@mail.windriver.com> (message from Margaret Wasserman on Sun, 30 Mar 2003 09:47:44 -0500) Subject: Re: Draft IPv6 Minutes from Atlanta IETF References: <068d01c2f58c$341b8300$ee1a4104@eagleswings> <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> <068d01c2f58c$341b8300$ee1a4104@eagleswings> <5.1.0.14.2.20030330092651.03674240@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > http://www.ietf.org/internet-drafts/draft-wasserman-ipv6-sl-impact-02.txt In above document... --- 3.1 The Fundamental Issue ... - The addresses are unreachable outside of their original context. ... --- Some may think the above is actually a benefit: all those organizations using the IPv4 private address spaces will want equivalent IPv6 space. They don't use the IPv4 private address space because of the address shortage. They use them exactly because those addressess cannot be used to communicate directly with outside internet. They are not NAT:ed. Millions of hosts inside corporate networks have only one address: the private IPv4 address. Even if IPv6 is enabled, the system administrator WILL not give global addresses to the internal nodes anyways. If site locals are not available, they invent something else for the purpose. The problem of address selection is red herring. In most cases, where site locals would be employed, the nodes would still have only one address: the site local address. Only some special nodes at the edges of the networks would need to deal with both global and site local. Using IPv4 private addresses as 6to4 addresses for the purpose is a hack. What is the point? Non-routable is non-routable. I definitely prefer a clean FEC0:: prefix for the purpose, instead of multiple 6to4 prefixes. -------------------------------------------------------------------- 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 Mar 30 09:37:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UHbpPL027937; Sun, 30 Mar 2003 09:37:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2UHbpJG027936; Sun, 30 Mar 2003 09:37:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UHbmPL027929 for ; Sun, 30 Mar 2003 09:37:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2UHbucU015630 for ; Sun, 30 Mar 2003 09:37:56 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21342 for ; Sun, 30 Mar 2003 09:37:50 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 17:37:30 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 17:37:30 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 17:37:30 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 17:37:29 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 5A9008A4A; Sun, 30 Mar 2003 19:37:26 +0200 (CEST) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id DAB50795A; Sun, 30 Mar 2003 19:37:14 +0200 (CEST) From: "Jeroen Massar" To: "'Mike Saywell'" , Subject: RE: A use for site local addresses? Date: Sun, 30 Mar 2003 19:38:17 +0200 Organization: Unfix Message-Id: <005801c2f6e3$29637c30$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <20030325115319.GI18295@ecs.soton.ac.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2UHbmPL027930 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike Saywell wrote: > On Tue, Mar 25, 2003 at 12:00:45PM +0100, Jeroen Massar wrote: > > Leif Johansson wrote: > > > > > Mark Thompson wrote: > > > > > > > > > > > > > > No matter how you capitalize the word, it still needs to > run the same > > > applications! Applications must not know about topology. Period. > > > > I am also *against* Link local. Not that this meant site local ofcourse as rectified in another message ;) > > > > IP's should be globably unique. Which will overcome many problems > > like network mergers ('oh we need to NAT now'), e2e problems etc. > > This is very true, but there are certain scenarios (like the > network I've described) where we have a need for a large > number of addresses, which dont require to be globally > routable (since network is self-contained). If the network is selfcontained then you neither have to uphold the rules of the internet relating to address usage. One could also simply start using 3f00::/8 for your self and nobody should complain. If you move from your self-contained network to a internet-connected network then you are bound to renumber anyways. There is no need to set aside numbering here and as we are talking about a /10 here that could count up one day. > If it was possible to use global addresses then I would, however rules > regarding the IPv6 address space allocation make this a near > impossibility for us. :( > > I can't really see the motivations to do NAT under v6 when > it's so easy to have multiple addresses on an interface > anyway. Joining 2 networks which use the same address > site-local addresses would be nowhere near as painfull > as before since it's that much easier to re-number one of > them under v6. It isn't all that much easier in v6 than in v4 if the site is using RA or DHCP (IPv4 has DHCP remember :) for configuring the networks. The 'pain' in renumbering is not the routing nor making the host get it's new prefix, it's all the databases and other configuration items that have to renumbered too. And I won't delve deeper into people using IP addresses in URL's to 'speed it up a bit' ;) But fortunatly for IPv6 the guidelines have changed there and browsers should not support it per default. Storing IP's in anything but DNS will cause headaches. One will need it to locate ones nameserver though but that should be solvable with DHCP and maybe one day even simple RA's... And if one is using static IPv4 it has the same pains as static IPv6. Nothing to work around there either. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 30 12:51:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UKpCPL028432; Sun, 30 Mar 2003 12:51:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2UKpCpq028431; Sun, 30 Mar 2003 12:51:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2UKp9PL028424 for ; Sun, 30 Mar 2003 12:51:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2UKpGcU024202 for ; Sun, 30 Mar 2003 12:51:16 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29234 for ; Sun, 30 Mar 2003 13:51:11 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 20:51:10 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 20:51:10 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 20:51:09 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Sun, 30 Mar 2003 20:51:09 Z Content-class: urn:content-classes:message Subject: RE: Draft IPv6 Minutes from Atlanta IETF MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 30 Mar 2003 12:51:09 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D47@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IPv6 Minutes from Atlanta IETF Thread-Index: AcL20V5cli/TE2CHTL+BWE1BYSi/SgAKcS7A From: "Michel Py" To: "Markku Savela" , "Margaret Wasserman" Cc: "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2UKp9PL028425 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Markku Savela wrote: > - The addresses are unreachable outside of their > original context. > Some may think the above is actually a benefit: > all those organizations using the IPv4 private > address spaces will want equivalent IPv6 space. Agree with Markku's post 100%. I have said I would support deprecation but certainly not before solutions to replaced what deprecation takes away are developed. There certainly are some issues with the scoped architecture and there also is the issue of private addresses with an architectural limitation to make them unroutable, please see one of my posts on the IETF list recently. "Just hijack a prefix that nobody else uses" is not an option and deprecation, should it happen, needs to provide a replacement for what it takes away _before_ it eventually happens. Michel. -------------------------------------------------------------------- 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 Mar 30 18:45:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V2jcPL029448; Sun, 30 Mar 2003 18:45:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2V2jboM029447; Sun, 30 Mar 2003 18:45:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V2jYPL029440 for ; Sun, 30 Mar 2003 18:45:34 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2V2jfHP003387 for ; Sun, 30 Mar 2003 18:45:42 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20056 for ; Sun, 30 Mar 2003 18:45:36 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:45:35 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:45:34 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:45:34 Z Received: from ALPHA6.ITS.MONASH.EDU.AU (ALPHA6.ITS.MONASH.EDU.AU [130.194.1.25]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:45:33 Z Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KU6AYCFZE095UONM@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 12:45:28 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id CB36820008; Mon, 31 Mar 2003 12:45:26 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id AA9DF20006; Mon, 31 Mar 2003 12:45:26 +1000 (EST) Date: Mon, 31 Mar 2003 12:45:26 +1000 From: Greg Daley Subject: Re: DAD in node requirements draft To: Mika Liljeberg Cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E87ABC6.1010304@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <20030326114233.12CAA791@starfruit.itojun.org> <1048701515.11083.19.camel@devil> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mika, just a quick comment on DAD-storms below. Mika Liljeberg wrote: > On Wed, 2003-03-26 at 13:42, Jun-ichiro itojun Hagino wrote: > >>>> note the mechanism is called DAD not DIID. this has >>>>been discussed to death numerous times, please refer to the archive. >>> >>>I know. Means people still disagree about it. >> >> how can you prevent random other node to assign P::X (which you are >> using and verified fe80::X by DAD) on the interface? > > > If X is a new ID for the other node, it would have to do DAD with > fe80::X. If the node alrady owns X, it could skip the DAD. > > In any case, I defend my id X against all possible prefix::X, so the > other node will no be able to take it no matter what prefix it uses. > > >> DIID does not work in practice. > > > It does work if everyone follows the same rules. > > Besides, if you do DAD for every address, a new prefix appearing in a RA > will cause a DAD storm as every node on the link will attempt to > configure a new address at the same time. This sounds just like the many-nodes-moving issue in MIPv6 which we're working on in mobile-ip. Current 2462/1 policy causes a delay of 0-1000ms for each DAD packet. So while there may be a storm, it shouldn't affect L2. Additionally, EUI-64 based addresses are only one of a set of available addresses now, with rfc3041 and CGA based addresses being possible. In these cases (manditorily in CGA) different suffixes are required for each address (local, global scope), so there is no gain from doing DIID. With 3041 addresses, we're still likely to see an additional EUI-64 based address for local comms anyway. I'd make the guess that at least 3041 addresses and possibly CGA-like addresses will be prevalent as IPv6 adoption continues. Greg -------------------------------------------------------------------- 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 Mar 30 18:49:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V2n3PL029468; Sun, 30 Mar 2003 18:49:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2V2n30W029467; Sun, 30 Mar 2003 18:49:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V2mxPL029460 for ; Sun, 30 Mar 2003 18:48:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2V2n6HP004028 for ; Sun, 30 Mar 2003 18:49:06 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11342 for ; Sun, 30 Mar 2003 19:48:59 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:48:01 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:18:31 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:21:36 Z Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 02:21:36 Z Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2V2LZM9011166 for ; Sun, 30 Mar 2003 19:21:36 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id TAA27217 for ; Sun, 30 Mar 2003 19:21:34 -0700 (MST)] Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h2V2LVmE001096 for ; Mon, 31 Mar 2003 12:21:32 +1000 (EST) Message-Id: <3E87A62B.39A476B8@motorola.com> Date: Mon, 31 Mar 2003 12:21:31 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Subject: Address scope, applications and site-local Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Applications should not need to know scope of addresses" I think this requirement is misleading. To invent some terminology, any address is both 'architecturally scoped' and 'functionally scoped'. * Architectural scoping: Over what scope is the address valid, in design? * Functional scoping: Over what scope is the address valid, in use? As Tony points out, an address may be globally unique, but not routeable on the global internet. This may be unwanted (broken links, bad routes) or wanted (explicit filters). Now, either we mandate that the model presented to applications is that the node has ONLY one address, or applications need to deal with the fact that both they and their target may have more than one address, and that these addresses may not be equally useful. This applies both to single and multiple interface multihoming. And exists already, in both IPv4 and IPv6. Applications need to deal with functional address scope, at least to the extent of retrying other source-destination combinations if the first fails. How does architectural scoping fit in? >From one perspective, architectural scoping is just a special case of functional scoping. Not only is this address functionally scoped, but we architecturally intend this to happen. Applications can ignore this information if they wish - functional scoping recovery will handle it. Or they can use it to bias their address selection choices. The unique issue raised by architectural scoping is ambiguity. However, most people who want site local addresses see this as a virtue. And again, there's no gain to applications by removing architecturally scoped addresses - functional scoping may mean that although A <-> B and B <-> C, A <-!-> C with the same addresses. There are a few situations where site-local addresses are very useful. If used outside those situations, they do not impose significant additional pain on applications. Applications already need to consider multiple addresses that may not be completely interchangeable. -- Andrew White Andrew.E.White@motorola.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 Sun Mar 30 23:59:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V7xaPL000685; Sun, 30 Mar 2003 23:59:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2V7xaD1000684; Sun, 30 Mar 2003 23:59:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V7xWPL000677 for ; Sun, 30 Mar 2003 23:59:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2V7xeHP027967 for ; Sun, 30 Mar 2003 23:59:40 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA19240 for ; Mon, 31 Mar 2003 00:59:31 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 07:59:12 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 07:59:12 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 07:59:11 Z Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [194.196.100.236]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 07:59:10 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2V7wXEO063862; Mon, 31 Mar 2003 09:58:33 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2V7wXkp233172; Mon, 31 Mar 2003 09:58:35 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47476 from ; Mon, 31 Mar 2003 09:58:32 +0200 Message-Id: <3E87F4E5.ACE43A2C@hursley.ibm.com> Date: Mon, 31 Mar 2003 09:57:25 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Tim Chown Cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> <3E846718.62F218E@hursley.ibm.com> <20030329133933.GF7796@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > > On Fri, Mar 28, 2003 at 04:15:36PM +0100, Brian E Carpenter wrote: > > I think you're missing Alain's point. If a host happens to have 2 addresses > > at a given moment, one left over from the disconnected state and one with > > the recently available connected prefix, either address will work fine for > > internal usage, and of course only the second one will work for external usage. > > > > This does lead to DDNS and 2 face DNS, but that's where we are heading > > in any case. > > So is it actually having a recommended prefix for disconnected networks > that's the issue, or having special scope prrocessing for a specific prefix, > or both? :) I think this is what Alain is indirectly asking/suggesting. When IPv6 began, it was certainly the disconnected sites argument that made me happy with site locals; but we hadn't thought through the scope issues or the issues of intermittently connected sites, and both of those are messy enough that I am now against site locals. Brian -------------------------------------------------------------------- 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 Mar 31 00:13:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V8DNPL000938; Mon, 31 Mar 2003 00:13:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2V8DNU3000937; Mon, 31 Mar 2003 00:13:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V8DJPL000927 for ; Mon, 31 Mar 2003 00:13:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2V8DSHP001169 for ; Mon, 31 Mar 2003 00:13:28 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06876 for ; Mon, 31 Mar 2003 01:13:21 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:09:32 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:09:31 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:09:31 Z Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:09:28 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2V89GOI026238 for ; Mon, 31 Mar 2003 10:09:16 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2V89Hkp279704 for ; Mon, 31 Mar 2003 10:09:18 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34180 from ; Mon, 31 Mar 2003 10:09:15 +0200 Message-Id: <3E87F768.37C15B67@hursley.ibm.com> Date: Mon, 31 Mar 2003 10:08:08 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft IPv6 Minutes from Atlanta IETF References: <068d01c2f58c$341b8300$ee1a4104@eagleswings> <4.3.2.7.2.20030328130152.02a28ee0@mailhost.iprg.nokia.com> <068d01c2f58c$341b8300$ee1a4104@eagleswings> <5.1.0.14.2.20030330092651.03674240@mail.windriver.com> <200303301524.h2UFOKux027508@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: ... > Even if IPv6 is enabled, the system administrator WILL not give global > addresses to the internal nodes anyways. If site locals are not > available, they invent something else for the purpose. Access control lists in routers were in use for this years before RFC 1597. Preventing unwanted access has never been a valid argument for private addresses and never will be. Brian -------------------------------------------------------------------- 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 Mar 31 00:17:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V8H8PL001017; Mon, 31 Mar 2003 00:17:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2V8H8D7001016; Mon, 31 Mar 2003 00:17:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V8H4PL001006 for ; Mon, 31 Mar 2003 00:17:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2V8HCHP002072 for ; Mon, 31 Mar 2003 00:17:12 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26961 for ; Mon, 31 Mar 2003 01:17:05 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:08:35 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:08:34 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:08:34 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 08:08:34 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA16656 for ; Mon, 31 Mar 2003 09:08:26 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id JAA14113 for ; Mon, 31 Mar 2003 09:08:25 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2V88P403990 for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 09:08:25 +0100 Date: Mon, 31 Mar 2003 09:08:25 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030331080825.GD3953@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> <3E846718.62F218E@hursley.ibm.com> <20030329133933.GF7796@login.ecs.soton.ac.uk> <3E87F4E5.ACE43A2C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E87F4E5.ACE43A2C@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 31, 2003 at 09:57:25AM +0200, Brian E Carpenter wrote: > > When IPv6 began, it was certainly the disconnected sites argument that > made me happy with site locals; but we hadn't thought through the scope > issues or the issues of intermittently connected sites, and both of those > are messy enough that I am now against site locals. So, as Michel asked, what's the solution for intermittently connected sites in the absence of site locals? 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 Mar 31 01:48:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V9mlPL001969; Mon, 31 Mar 2003 01:48:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2V9mlGZ001968; Mon, 31 Mar 2003 01:48:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2V9miPL001961 for ; Mon, 31 Mar 2003 01:48:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2V9mqcU021280 for ; Mon, 31 Mar 2003 01:48:52 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28339 for ; Mon, 31 Mar 2003 02:48:46 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 09:48:18 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 09:44:59 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 09:48:06 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 09:48:05 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h2V9lvdk095756 for ; Mon, 31 Mar 2003 11:47:58 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2V9lxkp287176 for ; Mon, 31 Mar 2003 11:48:00 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34990 from ; Mon, 31 Mar 2003 11:47:58 +0200 Message-Id: <3E880E8B.545ECE6E@hursley.ibm.com> Date: Mon, 31 Mar 2003 11:46:51 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> <3E846718.62F218E@hursley.ibm.com> <20030329133933.GF7796@login.ecs.soton.ac.uk> <3E87F4E5.ACE43A2C@hursley.ibm.com> <20030331080825.GD3953@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > > On Mon, Mar 31, 2003 at 09:57:25AM +0200, Brian E Carpenter wrote: > > > > When IPv6 began, it was certainly the disconnected sites argument that > > made me happy with site locals; but we hadn't thought through the scope > > issues or the issues of intermittently connected sites, and both of those > > are messy enough that I am now against site locals. > > So, as Michel asked, what's the solution for intermittently connected sites > in the absence of site locals? Well, I'd hoped to avoid that question until we had mailing list consensus on deprecating SLs. But since you ask, I think it has to be some form of GUPI prefix, plus of course a PA prefix during periods of connection. Brian -------------------------------------------------------------------- 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 Mar 31 02:11:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VABOPL002608; Mon, 31 Mar 2003 02:11:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VABO9r002607; Mon, 31 Mar 2003 02:11:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VABLPL002600 for ; Mon, 31 Mar 2003 02:11:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VABTcU025943 for ; Mon, 31 Mar 2003 02:11:29 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21965 for ; Mon, 31 Mar 2003 03:11:22 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:10:50 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:10:50 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:10:49 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:10:48 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA18586 for ; Mon, 31 Mar 2003 11:10:44 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id LAA24057 for ; Mon, 31 Mar 2003 11:10:44 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2VAAim06220 for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 11:10:44 +0100 Date: Mon, 31 Mar 2003 11:10:44 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? Message-Id: <20030331101044.GE5850@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> <3E846718.62F218E@hursley.ibm.com> <20030329133933.GF7796@login.ecs.soton.ac.uk> <3E87F4E5.ACE43A2C@hursley.ibm.com> <20030331080825.GD3953@login.ecs.soton.ac.uk> <3E880E8B.545ECE6E@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E880E8B.545ECE6E@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 31, 2003 at 11:46:51AM +0200, Brian E Carpenter wrote: > Tim Chown wrote: > > > > On Mon, Mar 31, 2003 at 09:57:25AM +0200, Brian E Carpenter wrote: > > > > > > When IPv6 began, it was certainly the disconnected sites argument that > > > made me happy with site locals; but we hadn't thought through the scope > > > issues or the issues of intermittently connected sites, and both of those > > > are messy enough that I am now against site locals. > > > > So, as Michel asked, what's the solution for intermittently connected sites > > in the absence of site locals? > > Well, I'd hoped to avoid that question until we had mailing list consensus > on deprecating SLs. I think (even) more people would back the deprecation of the specific "problem" cases can be addressed first. 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 Mar 31 02:39:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VAdNPL003123; Mon, 31 Mar 2003 02:39:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VAdNbC003122; Mon, 31 Mar 2003 02:39:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VAdKPL003115 for ; Mon, 31 Mar 2003 02:39:20 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VAdSHP029681 for ; Mon, 31 Mar 2003 02:39:28 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19785 for ; Mon, 31 Mar 2003 02:39:22 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:39:21 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:39:21 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:39:21 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 10:39:21 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2VAcjS02434; Mon, 31 Mar 2003 13:38:45 +0300 Date: Mon, 31 Mar 2003 13:38:45 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? In-Reply-To: <20030331080825.GD3953@login.ecs.soton.ac.uk> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 31 Mar 2003, Tim Chown wrote: > On Mon, Mar 31, 2003 at 09:57:25AM +0200, Brian E Carpenter wrote: > > > > When IPv6 began, it was certainly the disconnected sites argument that > > made me happy with site locals; but we hadn't thought through the scope > > issues or the issues of intermittently connected sites, and both of those > > are messy enough that I am now against site locals. > > So, as Michel asked, what's the solution for intermittently connected sites > in the absence of site locals? Route advertisements with long-enough lifetimes and fast-enough _deprecation_ (when reconnecting) seems one approach to look at more closely, IMO. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 31 04:43:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VChhPL003615; Mon, 31 Mar 2003 04:43:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VChhv3003614; Mon, 31 Mar 2003 04:43:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VChePL003607 for ; Mon, 31 Mar 2003 04:43:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VChlcU023620 for ; Mon, 31 Mar 2003 04:43:47 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05622 for ; Mon, 31 Mar 2003 05:43:41 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 12:43:39 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 12:43:20 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 12:43:20 Z Received: from c001.snv.cp.net ([209.228.32.127] [209.228.32.127]) by relay11.sun.com for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 12:43:18 Z Received: (cpmta 29211 invoked from network); 31 Mar 2003 04:43:13 -0800 Received: from 32.102.11.75 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 31 Mar 2003 04:43:13 -0800 X-Sent: 31 Mar 2003 12:43:13 GMT Message-Id: <004c01c2f783$4dbbe090$4b0b6620@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> <3E846718.62F218E@hursley.ibm.com> <20030329133933.GF7796@login.ecs.soton.ac.uk> <3E87F4E5.ACE43A2C@hursley.ibm.com> <20030331080825.GD3953@login.ecs.soton.ac.uk> <3E880E8B.545ECE6E@hursley.ibm.com> Subject: Re: A use for site local addresses? Date: Mon, 31 Mar 2003 15:44:40 +0300 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 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Well, I'd hoped to avoid that question until we had mailing list consensus > on deprecating SLs. > I would tend to say that we are a long way from consensus about SL's. -------------------------------------------------------------------- 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 Mar 31 06:48:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VEmPPL004188; Mon, 31 Mar 2003 06:48:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VEmP8f004187; Mon, 31 Mar 2003 06:48:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VEmLPL004180 for ; Mon, 31 Mar 2003 06:48:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VEmSHP012929 for ; Mon, 31 Mar 2003 06:48:29 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14061 for ; Mon, 31 Mar 2003 07:48:22 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 14:43:34 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 14:43:33 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 14:43:32 Z Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 14:43:31 Z Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h2VEhPdk072224 for ; Mon, 31 Mar 2003 16:43:25 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2VEhAkp094078 for ; Mon, 31 Mar 2003 16:43:20 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA34404 from ; Mon, 31 Mar 2003 16:42:52 +0200 Message-Id: <3E8853A9.66D4DD04@hursley.ibm.com> Date: Mon, 31 Mar 2003 16:41:45 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Node requirements re RFC 2893 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-ipv6-node-requirements-03.txt includes: > 6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 > > If an IPv6 node implement dual stack and/or tunneling, then RFC2893 > MUST be supported. This is a little unclear due to the "and/or". Could we have If an IPv6 node implements dual stack operation, or IPv6-in-IPv4 tunneling, or both, then the relevant sections of RFC2893 MUST be supported. Brian -------------------------------------------------------------------- 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 Mar 31 07:16:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFGjPL004850; Mon, 31 Mar 2003 07:16:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VFGivO004849; Mon, 31 Mar 2003 07:16:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFGfPL004842 for ; Mon, 31 Mar 2003 07:16:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VFGnHP019494 for ; Mon, 31 Mar 2003 07:16:49 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25240 for ; Mon, 31 Mar 2003 07:16:43 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:16:42 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:16:23 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:16:23 Z Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:16:21 Z Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2VFGI33083218 for ; Mon, 31 Mar 2003 17:16:18 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2VFGINt281716 for ; Mon, 31 Mar 2003 17:16:19 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA23140 from ; Mon, 31 Mar 2003 17:16:17 +0200 Message-Id: <3E885B7E.B4098B70@hursley.ibm.com> Date: Mon, 31 Mar 2003 17:15:10 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: A use for site local addresses? References: <006301c2f532$aa94e5d0$2eef1891@unfix.org> <3E846718.62F218E@hursley.ibm.com> <20030329133933.GF7796@login.ecs.soton.ac.uk> <3E87F4E5.ACE43A2C@hursley.ibm.com> <20030331080825.GD3953@login.ecs.soton.ac.uk> <3E880E8B.545ECE6E@hursley.ibm.com> <004c01c2f783$4dbbe090$4b0b6620@ttitelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk EricLKlein wrote: > > Brian E Carpenter wrote: > > Well, I'd hoped to avoid that question until we had mailing list consensus > > on deprecating SLs. > > > > I would tend to say that we are a long way from consensus about SL's. Tony's draft (http://www.tndh.net/~tony/ietf/site-local.txt) makes a good case for globally unique provider independent addresses with a non-routeability option. It would be interesting to know if we have consensus about that. IMHO it doesn't make a case for SLs in their present incarnation (i.e. ambiguous address space). There is a lot of operational pain in ambiguous address, once you start building VPNs between business partners or otherwise merging "private" networks. I think we should also seek consensus that ambiguous addresses are unacceptable. Brian -------------------------------------------------------------------- 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 Mar 31 07:35:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFZ8PL005384; Mon, 31 Mar 2003 07:35:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VFZ8r8005383; Mon, 31 Mar 2003 07:35:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFZ5PL005376 for ; Mon, 31 Mar 2003 07:35:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VFZCHP023935 for ; Mon, 31 Mar 2003 07:35:12 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18944 for ; Mon, 31 Mar 2003 08:35:06 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:35:00 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:31:49 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:31:49 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:31:48 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA21023; Mon, 31 Mar 2003 07:31:00 -0800 (PST) Message-Id: <5.1.0.14.2.20030331101959.01465bd8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 31 Mar 2003 10:29:20 -0500 To: "Jeroen Massar" From: Margaret Wasserman Subject: RE: avoiding NAT with IPv6 Cc: "'BINET David FTRD/DMI/CAE'" , "'JORDI PALET MARTINEZ'" , In-Reply-To: <000701c2ef28$75ff2160$210d640a@unfix.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jeroen, >In IPv6 every enduser should have enough IP's simply >because of the simple rule [...] > >Nevertheless customers should never have any need whatsoever for NAT. >If there once is a need for it IPv6 'failed' as it didn't get up to >the primary need for IPv6: More addressspace so that everything can be >e2e. Unfortunately, there is another reason why enterprises use NAT that has not been addressed in IPv6: provider independence. Enterprises do not want to be "held hostage" to a particular ISP based on their address usage -- they want it to be cheap to move between ISPs to gain rate advantages, and they don't want to be adversely affected by ISP closures, mergers, etc. By using internal addresses inside of their network, and using NAT to reach the global Internet, only a few systems need to be renumbered when ISP-provided global addresses change. So, if we don't come up with a way to allow provider-independent address allocation in IPv6, we will probably get IPv6<->IPv6 NAT. Unfortunately, we don't have a proven/accepted method for doing provider independent address allocation that will scale -- the most obvious methods would all result in much larger core routing tables, and won't scale to Internet proportions. There are folks working on solutions to this problem (both in the IETF and the IRTF), and those solutions are the best hope that we have to avoid NAT. In the meantime, though, I wouldn't object to a statement in the IPv6 node requirements that says that you MUST NOT translate source or destination addresses in forwarded packets... even though I don't think that it will actually stop anyone. Margaret -------------------------------------------------------------------- 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 Mar 31 07:50:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFo5PL005619; Mon, 31 Mar 2003 07:50:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VFo5YE005618; Mon, 31 Mar 2003 07:50:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFo1PL005605 for ; Mon, 31 Mar 2003 07:50:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VFo8HP028277 for ; Mon, 31 Mar 2003 07:50:08 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25572 for ; Mon, 31 Mar 2003 08:50:01 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:48:34 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:45:27 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:48:33 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:48:33 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA29749; Mon, 31 Mar 2003 07:48:00 -0800 (PST) Message-Id: <5.1.0.14.2.20030331104036.048d6590@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 31 Mar 2003 10:44:00 -0500 To: Siva Veerepalli From: Margaret Wasserman Subject: Re: Updates to PPPv6 Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4.3.2.7.2.20030318111531.01419cd8@jittlov.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Siva, During our 3GPP-related work last year, there were several comments that indicated that the wording of the PPPv6 spec is somewhat unclear. In particular, it seems to indicate the the address that is negotiated via PPP will be the only address in use on the client end of the PPP connection. At that time, we agreed to review the document and clear up the single-address assumptions, if any. There may also be other issues that have been sent to the authors. It is likely that all of the changes would be editorial, but I don't know for sure. I also don't know if it makes the most sense to do this work in the IPv6 WG or in the PPP Extensions WG -- this might depend on the scope of changes required. We should be starting up an effort on this in the next couple of months. Margaret At 11:17 AM 3/18/2003 -0800, Siva Veerepalli wrote: >The current work items in the wg charter and Margaret's presentation on >document status in the WG meeting shows PPPv6 as one of the items. Could >someone clarify what changes/updates are being considered for IPv6 over >PPP rfc? Are they technical or editorial/clarification of existing text? > >I meant to send this mail to the rfc authors, but their email addresses on >the rfc are not current. > >Thanks, >Siva >-------------------------------------------------------------------- >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 Mar 31 07:58:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFwYPL005817; Mon, 31 Mar 2003 07:58:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VFwY5C005815; Mon, 31 Mar 2003 07:58:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VFwTPL005805 for ; Mon, 31 Mar 2003 07:58:29 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VFwacU008329 for ; Mon, 31 Mar 2003 07:58:37 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12056 for ; Mon, 31 Mar 2003 07:58:31 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:58:30 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:58:28 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:58:28 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 15:58:28 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA04437; Mon, 31 Mar 2003 07:57:59 -0800 (PST) Message-Id: <5.1.0.14.2.20030331104602.04979c80@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 31 Mar 2003 10:48:23 -0500 To: "Bound, Jim" From: Margaret Wasserman Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] Cc: "Brian E Carpenter" , In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD23@tayexc13.americas .cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 Node Requirements is intended to document the minimal requirements for an IPv6 node, and a DNS resolver is not one of those requirements. You can have a perfectly-compliant IPv6 node that doesn't include any DNS support. If we start down the road of saying: "A node MUST include a DNS resolver if it needs to resolve DNS names." wouldn't this lead to: "A node MUST include SIP if it wants to use the Session Initiation Protocol", etc.? Margaret At 06:45 PM 3/18/2003 -0500, Bound, Jim wrote: >Agreed. But how can a node find an address without MUST DNS. The point >is that a requirement to use is based on the situation. My point last >night. > >/jim > > > > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Tuesday, March 18, 2003 4:45 PM > > To: Bound, Jim > > Cc: ipng@sunroof.eng.sun.com > > Subject: 5.2 DNS [Re: Nodes Requirements Input] > > > > > > "Bound, Jim" wrote: > > ... > > > > > > > > 5.2 DNS > > > > > > > > DNS, as described in [RFC-1034], [RFC-1035], > > [RFC-1886], [RFC-3152] > > > > and [RFC-3363] MAY be supported. Not all nodes will need to > > > > resolve > > > > addresses. Note that RFC 1886 is currently being updated > > > > [RFC-1886- > > > > BIS]. > > > > > > DNS "use" is a MUST for correct node operation. MAY is absurd. > > > > Why would a thermostat need to resolve names? > > > > Brian > > > >-------------------------------------------------------------------- >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 Mar 31 08:52:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VGqKPL006487; Mon, 31 Mar 2003 08:52:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VGqKJx006486; Mon, 31 Mar 2003 08:52:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VGqGPL006479 for ; Mon, 31 Mar 2003 08:52:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VGqOHP016893 for ; Mon, 31 Mar 2003 08:52:24 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15977 for ; Mon, 31 Mar 2003 09:52:17 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:52:13 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:52:13 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:52:13 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:52:12 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 899A78AAC; Mon, 31 Mar 2003 18:52:09 +0200 (CEST) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 5E7AC89DF; Mon, 31 Mar 2003 18:52:03 +0200 (CEST) From: "Jeroen Massar" To: "'Margaret Wasserman'" Cc: Subject: RE: avoiding NAT with IPv6 Date: Mon, 31 Mar 2003 18:53:08 +0200 Organization: Unfix Message-Id: <003601c2f7a6$02f57df0$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.2.20030331101959.01465bd8@mail.windriver.com> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VGqHPL006480 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman [mailto:mrw@windriver.com] wrote: > Hi Jeroen, > > >In IPv6 every enduser should have enough IP's simply > >because of the simple rule [...] > > > >Nevertheless customers should never have any need whatsoever for NAT. > >If there once is a need for it IPv6 'failed' as it didn't get up to > >the primary need for IPv6: More addressspace so that > everything can be > >e2e. > > Unfortunately, there is another reason why enterprises use > NAT that has not been addressed in IPv6: provider independence. > > Enterprises do not want to be "held hostage" to a particular ISP based > on their address usage -- they want it to be cheap to move > between ISPs to gain rate advantages, and they don't want to be adversely affected > by ISP closures, mergers, etc. By using internal addresses inside of > their network, and using NAT to reach the global Internet, only a few > systems need to be renumbered when ISP-provided global addresses change. These enterprises apparently don't want/require/need global reachability for their hosts. Otherwise they would not NAT. IMHO the real solution to this and some other problems we are currently seeing in IPv6 is really one thing which must be solved before anything else: IPv6 Multihoming Another solution could be a good document outlining all the problems along with possible solutions when a network gets renumbered. IP renumbering isn't that much of a problem but renumbering the configuration items which contain IP's is. > So, if we don't come up with a way to allow > provider-independent address > allocation in IPv6, we will probably get IPv6<->IPv6 NAT. We don't want PI because that would also imply a routingtable explosion. PI thus is not the answer. > In the meantime, though, I wouldn't object to a statement in the IPv6 > node requirements that says that you MUST NOT translate source or > destination addresses in forwarded packets... even though I don't > think that it will actually stop anyone. I do agree for the fact that this would overcome a NAT. But I see one quite legit reason for rewriting the source/destination. Though it could quite probably be solved in a different way: loadbalancers. A loadbalancer can easily rewrite the destination IPv6 IP and then route it to the destination back-end which won't notice that it's held behind a loadbalancer. On outgoing the loadbalancer rewrites the source IP to that of the loadbalancer. The boxes behind the loadbalancer can simply be on a /64 which is not routeable to the internet or even easier: link local Thus the loadbalancer is simply a NAT which spreads incoming connects evenly over the backends which are alive. Note that I would really like to see a loadbalancer which sports both IPv4 and IPv6, as this would make many sites which actively use loadbalancers actually start providing theirselves over IPv6. Taking a, imho, good application like the above in view NAT should not be forbidden... (Then again, the loadbalancer could just also have all the backends configured with the global IP and just forward the packets to the correct box... hmmm ;) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 31 09:00:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VH00PL006761; Mon, 31 Mar 2003 09:00:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VH00fH006760; Mon, 31 Mar 2003 09:00:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VGxuPL006753 for ; Mon, 31 Mar 2003 08:59:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VH03cU027178 for ; Mon, 31 Mar 2003 09:00:04 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29893 for ; Mon, 31 Mar 2003 08:59:57 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:59:55 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:59:49 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:59:49 Z Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:59:48 Z Received: from repligate ([67.36.180.12]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030331165946.WBDQ11905.mailhost.chi1.ameritech.net@repligate>; Mon, 31 Mar 2003 10:59:46 -0600 Message-Id: <02dd01c2f7a6$f04cec00$8500a8c0@repligate> From: "Jim Fleming" To: "Jeroen Massar" , "Margaret Wasserman" Cc: "'BINET David FTRD/DMI/CAE'" , "'JORDI PALET MARTINEZ'" , References: <5.1.0.14.2.20030331101959.01465bd8@mail.windriver.com> Subject: "...we don't have a proven/accepted method..." ? Date: Mon, 31 Mar 2003 10:59:38 -0600 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: "Margaret Wasserman" "Unfortunately, we don't have a proven/accepted method for doing provider independent address allocation that will scale..." ==== Since you do not have a "proven/accepted" method, people can just route around the situation and that becomes a proven/accepted method.... 128-bit DNS AAAA Record Flag Day Formats 2003:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("AM/FM") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt IPv8 0QQQQGGGSSSSSSSS[32-bits][Port] IPv16 0QQQQGGGSSSSSSSS[32-bits][Port] 1AAAAAAAAAAAAAAA[32-bits][Port] A...A=ASN=32769...65535 Jim Fleming http://www.IPv8.info ----- Original Message ----- From: "Margaret Wasserman" To: "Jeroen Massar" Cc: "'BINET David FTRD/DMI/CAE'" ; "'JORDI PALET MARTINEZ'" ; Sent: Monday, March 31, 2003 9:29 AM Subject: RE: avoiding NAT with IPv6 > > Hi Jeroen, > > >In IPv6 every enduser should have enough IP's simply > >because of the simple rule [...] > > > >Nevertheless customers should never have any need whatsoever for NAT. > >If there once is a need for it IPv6 'failed' as it didn't get up to > >the primary need for IPv6: More addressspace so that everything can be > >e2e. > > Unfortunately, there is another reason why enterprises use NAT that has > not been addressed in IPv6: provider independence. > > Enterprises do not want to be "held hostage" to a particular ISP based > on their address usage -- they want it to be cheap to move between ISPs > to gain rate advantages, and they don't want to be adversely affected > by ISP closures, mergers, etc. By using internal addresses inside of > their network, and using NAT to reach the global Internet, only a few > systems need to be renumbered when ISP-provided global addresses change. > > So, if we don't come up with a way to allow provider-independent address > allocation in IPv6, we will probably get IPv6<->IPv6 NAT. > > Unfortunately, we don't have a proven/accepted method for doing provider > independent address allocation that will scale -- the most obvious > methods would all result in much larger core routing tables, and won't > scale to Internet proportions. There are folks working on solutions > to this problem (both in the IETF and the IRTF), and those solutions > are the best hope that we have to avoid NAT. > > In the meantime, though, I wouldn't object to a statement in the IPv6 > node requirements that says that you MUST NOT translate source or > destination addresses in forwarded packets... even though I don't > think that it will actually stop anyone. > > Margaret > > > > > -------------------------------------------------------------------- > 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 Mar 31 09:03:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VH3PPL006980; Mon, 31 Mar 2003 09:03:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VH3PXw006979; Mon, 31 Mar 2003 09:03:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VH3LPL006969 for ; Mon, 31 Mar 2003 09:03:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VH3SHP020585 for ; Mon, 31 Mar 2003 09:03:29 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28349 for ; Mon, 31 Mar 2003 10:03:22 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:03:17 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 16:59:57 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:03:04 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:03:04 Z Content-class: urn:content-classes:message Subject: RE: Draft IPv6 Minutes from Atlanta IETF MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 2003 09:03:01 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D4C@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IPv6 Minutes from Atlanta IETF Thread-Index: AcL3XulVi58B5nClSn+GuPrHgUUKaAAQpf8Q From: "Michel Py" To: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VH3MPL006970 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian E Carpenter wrote: > Access control lists in routers were in use for > this years before RFC 1597. Preventing unwanted > access has never been a valid argument for private > addresses and never will be. I have to disagree with this. There are some legitimate cases of using private addresses for security purposes in "defense in depth" scenarios that Richard Draves and I described earlier. This creates demand for them. However, the issue has nothing to do with technical reasons and everything to do with this organization designing protocols without paying attention to customer needs and getting us into the same circle one more time. Private addresses != NAT. Perception == reality. Private addresses == security. Network administrators want security. Network administrators want private addresses. Ignoring this fact will lead us in network administrators hijacking prefixes again; then some vendor will produce a de-facto hack for them, likely the hack will fall under the umbrella of one of these mighty corporations that according to popular belief produce junk, then everyone will be complaining about big mighty corporations producing proprietary junk, but we will produce an RFC to rubber stamp the de-facto junk and the loop will be closed. Please, not one more time. There is a need for private addresses, if we don't provide a solution the market will and we're not going to be happy with it. As Margaret pointed out, > Margaret Wasserman wrote: > Unfortunately, there is another reason why enterprises > use NAT that has not been addressed in IPv6: provider > independence. Although one of the big driving forces behind NAT is the lack of PI addresses, there is an aggravating factor which is the ambiguity of private addresses, which eventually leads to internal NAT when sites merge. It is allowed to hope that this factor alone would not trigger NAT happening if the PI issue was solved, but why take a chance? We need private addresses, and preferably unique ones. In order to achieve this we need some kind of architectural limitation to replace the fact that ambiguity guaranteed non-routability of private addresses. Keep in mind that we don't need non-routability of private addresses for security reasons, we need it to ensure there is no routing table explosion. Site-locals provide this architectural limitation. What do we have to replace it? Nothing. People hijacking prefixes will re-introduce most of the problems that site-locals have, putting them under the rug does not solve them. I understand that there are problems with site-locals, but deprecating them should not introduce new issues. Let's be careful not to have a cure that is worse than the disease. Michel. -------------------------------------------------------------------- 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 Mar 31 09:21:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHLpPL007480; Mon, 31 Mar 2003 09:21:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VHLpf8007479; Mon, 31 Mar 2003 09:21:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHLlPL007469 for ; Mon, 31 Mar 2003 09:21:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VHLsHP026562 for ; Mon, 31 Mar 2003 09:21:54 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29857 for ; Mon, 31 Mar 2003 10:21:44 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:21:41 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:21:41 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:21:40 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:21:40 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 31 Mar 2003 09:21:36 -0800 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , Subject: RE: Draft IPv6 Minutes from Atlanta IETF Date: Mon, 31 Mar 2003 09:21:36 -0800 Message-Id: <076701c2f7a9$fc195ed0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E87F768.37C15B67@hursley.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Markku Savela wrote: > > ... > > Even if IPv6 is enabled, the system administrator WILL not > give global > > addresses to the internal nodes anyways. If site locals are not > > available, they invent something else for the purpose. > > Access control lists in routers were in use for this years > before RFC 1597. Preventing unwanted access has never been a > valid argument for private addresses and never will be. Let's try to be very crisp with the terms we are using. Private addresses are exactly about preventing unwanted access. I believe your intent was to say they are not an argument for ambiguous addresses. In the case of self controlled filters I would agree that the ambiguity of the address is of limited value. In the case where a third party is also responsible for some of that filtering, there is value in having the world know to also filter. Tony -------------------------------------------------------------------- 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 Mar 31 09:26:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHQtPL007515; Mon, 31 Mar 2003 09:26:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VHQt1A007514; Mon, 31 Mar 2003 09:26:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHQqPL007507 for ; Mon, 31 Mar 2003 09:26:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VHQwHP028117 for ; Mon, 31 Mar 2003 09:26:59 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02339 for ; Mon, 31 Mar 2003 10:26:51 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:26:07 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:26:07 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:26:06 Z Received: from klapautius.it.su.se ([217.215.166.49] [217.215.166.49]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:26:05 Z Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h2VGLam23234; Mon, 31 Mar 2003 18:21:36 +0200 Message-Id: <3E886B10.9090004@it.su.se> Date: Mon, 31 Mar 2003 18:21:36 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Jeroen Massar , "'BINET David FTRD/DMI/CAE'" , "'JORDI PALET MARTINEZ'" , ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 References: <5.1.0.14.2.20030331101959.01465bd8@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030331101959.01465bd8@mail.windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > > > In the meantime, though, I wouldn't object to a statement in the IPv6 > node requirements that says that you MUST NOT translate source or > destination addresses in forwarded packets... even though I don't > think that it will actually stop anyone. > I think this is a good plan. Clearly people will find ways to shoot themselves in the foot but the gun should not be part of the required infrastructure. MVH leifj -------------------------------------------------------------------- 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 Mar 31 09:29:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHTQPL007611; Mon, 31 Mar 2003 09:29:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VHTQqL007610; Mon, 31 Mar 2003 09:29:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHTMPL007603 for ; Mon, 31 Mar 2003 09:29:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VHTUHP029117 for ; Mon, 31 Mar 2003 09:29:30 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17832 for ; Mon, 31 Mar 2003 10:29:23 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:27:47 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:27:43 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:27:43 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:27:42 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 31 Mar 2003 09:27:37 -0800 Reply-To: From: "Tony Hain" To: "'Pekka Savola'" , "'Tim Chown'" Cc: Subject: RE: A use for site local addresses? Date: Mon, 31 Mar 2003 09:27:37 -0800 Message-Id: <076801c2f7aa$d5126a10$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > Route advertisements with long-enough lifetimes and > fast-enough _deprecation_ (when reconnecting) seems one > approach to look at more > closely, IMO. Rather than continue to send this nonsense, please look closely at it because you will find that it is a seriously broken model. Deprecation at reconnection will cause internal connections to drop. If you delay the deprecation, connections to the site with the valid allocation will not be possible. This is not a valid approach. Tony -------------------------------------------------------------------- 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 Mar 31 09:43:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHh1PL008448; Mon, 31 Mar 2003 09:43:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VHh0K3008447; Mon, 31 Mar 2003 09:43:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHguPL008434 for ; Mon, 31 Mar 2003 09:42:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VHh4cU013365 for ; Mon, 31 Mar 2003 09:43:04 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06069 for ; Mon, 31 Mar 2003 09:42:58 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:42:57 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:42:57 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:42:57 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:42:57 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 31 Mar 2003 09:42:55 -0800 Reply-To: From: "Tony Hain" To: "'Brian E Carpenter'" , Subject: RE: A use for site local addresses? Date: Mon, 31 Mar 2003 09:42:56 -0800 Message-Id: <076901c2f7ac$f7017a60$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E885B7E.B4098B70@hursley.ibm.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VHgvPL008435 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > EricLKlein wrote: > > > > Brian E Carpenter wrote: > > > Well, I'd hoped to avoid that question until we had mailing list > > > consensus on deprecating SLs. > > > > > > > I would tend to say that we are a long way from consensus > about SL's. That is the understatement of the day... > > Tony's draft (http://www.tndh.net/~tony/ietf/site-local.txt) > makes a good case for globally unique provider independent > addresses with a non-routeability option. It would be > interesting to know if we have consensus about that. Keep in mind it was a quick hack from prior email, so there may be other points that people want addressed. > > IMHO it doesn't make a case for SLs in their present > incarnation (i.e. ambiguous address space). There is a lot of > operational pain in ambiguous address, once you start > building VPNs between business partners or otherwise merging > "private" networks. I think we should also seek consensus > that ambiguous addresses are unacceptable. I agree ambiguous addresses are unacceptable for some purposes, but that does not mean all uses are invalid. Maybe the real problem here is that we only provide a site controlled address space that is ambiguous. If we had a PI space, I believe there would be no need to argue about keeping/deprecating the ambiguous space. It sounds like your issue is with the logic about prefering the short /10. If we dropped the logic and added a flag in the RA to indicate the prefix applications should prefer to cover the intermittently connected case, would you still have an issue with the ambiguous addresses existing? Tony -------------------------------------------------------------------- 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 Mar 31 09:48:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHmWPL008628; Mon, 31 Mar 2003 09:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VHmWAj008627; Mon, 31 Mar 2003 09:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VHmTPL008620 for ; Mon, 31 Mar 2003 09:48:29 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VHmaHP007321 for ; Mon, 31 Mar 2003 09:48:36 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10463 for ; Mon, 31 Mar 2003 09:48:30 -0800 (PST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:48:30 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:48:30 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:48:30 Z Received: from mail.wrs.com ([147.11.1.11] [147.11.1.11]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 17:48:29 Z Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA07240; Mon, 31 Mar 2003 09:48:01 -0800 (PST) Message-Id: <5.1.0.14.2.20030331123119.04a61410@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 31 Mar 2003 12:42:48 -0500 To: "Jeroen Massar" From: Margaret Wasserman Subject: RE: avoiding NAT with IPv6 Cc: In-Reply-To: <003601c2f7a6$02f57df0$210d640a@unfix.org> References: <5.1.0.14.2.20030331101959.01465bd8@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jeroen, >These enterprises apparently don't want/require/need global >reachability for their hosts. Otherwise they would not NAT. That depends on what you mean by "global reachability". I am writing to you from behind a NAT right now. From here, I can reach web sites on the global Internet, etc. I can't run servers here, so I need to depend on my friends to do that for me. There is a big difference between IPv6 site-local addresses (whether "full", "moderate" or "exlusive") and the use of private addressing behind IPv4 NATs. Without NAT, nodes that only have an IPv6 site-local address will not be able to communicate with the global Internet _at all_. If you add a globally routed address to an IPv6 node (whether or not it already has a site-local address) it will be able to reach the global Internet, and nodes on the global Internet will be able to reach it. The one-way reachability (outbound, but not inbound) that is experienced by users of IPv4 NAT is a side-effect of NAT. So, if we are successful in avoiding NAT in IPv6, the "security" models that depend on this one-way reachability won't apply in IPv6. >IMHO the real solution to this and some other problems we >are currently seeing in IPv6 is really one thing which >must be solved before anything else: IPv6 Multihoming I'm not sure how IPv6 Multihoming applies here. Could you explain? > > So, if we don't come up with a way to allow > > provider-independent address > > allocation in IPv6, we will probably get IPv6<->IPv6 NAT. > >We don't want PI because that would also imply a routingtable >explosion. PI thus is not the answer. The simplest ways to provide PI addresses imply routing table explosion. There are people (in the IETF, IRTF and elsewhere) working on mechanisms for provider-independent addressing that avoid routing table explosion. I certainly hope that they will be successful, as that would solve a lot of problems. >Taking a, imho, good application like [loadbalancers] in view >NAT should not be forbidden... > >(Then again, the loadbalancer could just also have all the >backends configured with the global IP and just forward the >packets to the correct box... hmmm ;) I don't have any interest in eliminating load balancers, but are you sure that this is how they work? What happens when the server passes its IP addresses in FTP, SCTP or SIP packets (or any other application-layer protocol)? Does the loadbalancer also translate those addresses to point to the loadbalancer, or is it assumed that the client node can (and should) reach the server directly in those cases? Margaret -------------------------------------------------------------------- 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 Mar 31 10:11:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VIBvPL009638; Mon, 31 Mar 2003 10:11:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VIBvHj009637; Mon, 31 Mar 2003 10:11:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VIBsPL009630 for ; Mon, 31 Mar 2003 10:11:54 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VIC1HP016795 for ; Mon, 31 Mar 2003 10:12:01 -0800 (PST) Received: from relay12.sun.com (bt [150.143.167.24]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11379 for ; Mon, 31 Mar 2003 10:11:55 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:11:53 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:08:46 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:11:53 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:11:53 Z Content-class: urn:content-classes:message Subject: RE: avoiding NAT with IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 2003 10:11:52 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F54D4D@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcL3rsowetnP0oK+QsGBXKWBc/28/AAALPSw From: "Michel Py" To: "Margaret Wasserman" , "Jeroen Massar" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VIBsPL009631 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >> Jeroen Massar wrote: >> IMHO the real solution to this and some other >> problems we are currently seeing in IPv6 is >> really one thing which must be solved before >> anything else: IPv6 Multihoming > Margaret Wasserman wrote: > I'm not sure how IPv6 Multihoming applies here. > Could you explain? Scalable "PI-like" identifiers are a by-product of some multihoming solutions (this is the identifier/locator thing). It has been discussed whether or not to limit their scope to multihomers only, but in any case generalizing the multihoming solution to singlehomers to provide the benefits of a "PI-like" is a matter of policy, not protocol. In other words: it is possible indeed to look at solving the problem of PI scalability as a self-contained issue, but why? This is so deeply related to multihoming that the best way is to make sure that by-products of multihoming solutions do indeed provide a scalable PI-like solution for singlehomers. Michel. -------------------------------------------------------------------- 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 Mar 31 10:15:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VIFPPL009795; Mon, 31 Mar 2003 10:15:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VIFPNE009794; Mon, 31 Mar 2003 10:15:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VIFMPL009787 for ; Mon, 31 Mar 2003 10:15:22 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VIFTHP018462 for ; Mon, 31 Mar 2003 10:15:29 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02382 for ; Mon, 31 Mar 2003 10:15:23 -0800 (PST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:15:21 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:15:20 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:15:20 Z Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:15:20 Z Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id TAA26524 for ; Mon, 31 Mar 2003 19:15:19 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id TAA28215 for ; Mon, 31 Mar 2003 19:15:18 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2VIFIG25595 for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:15:18 +0100 Date: Mon, 31 Mar 2003 19:15:18 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 Message-Id: <20030331181518.GD25506@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <5.1.0.14.2.20030331101959.01465bd8@mail.windriver.com> <003601c2f7a6$02f57df0$210d640a@unfix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003601c2f7a6$02f57df0$210d640a@unfix.org> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 31, 2003 at 06:53:08PM +0200, Jeroen Massar wrote: > > These enterprises apparently don't want/require/need global > reachability for their hosts. Otherwise they would not NAT. So they probably don't want v6 either, so let them NAT with v4 only. 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 Mar 31 10:31:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VIVbPL010645; Mon, 31 Mar 2003 10:31:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VIVbnQ010644; Mon, 31 Mar 2003 10:31:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VIVXPL010636 for ; Mon, 31 Mar 2003 10:31:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VIVeHP024665 for ; Mon, 31 Mar 2003 10:31:41 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09315 for ; Mon, 31 Mar 2003 11:31:35 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:29:40 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:29:40 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:29:40 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 18:29:38 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id DCCD18AB7; Mon, 31 Mar 2003 20:29:20 +0200 (CEST) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id F0ECA8AA9; Mon, 31 Mar 2003 20:29:13 +0200 (CEST) From: "Jeroen Massar" To: "'Tim Chown'" , Subject: RE: avoiding NAT with IPv6 Date: Mon, 31 Mar 2003 20:30:19 +0200 Organization: Unfix Message-Id: <005001c2f7b3$96299770$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030331181518.GD25506@login.ecs.soton.ac.uk> Importance: Normal X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VIVYPL010638 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim Chown wrote: > On Mon, Mar 31, 2003 at 06:53:08PM +0200, Jeroen Massar wrote: > > > > These enterprises apparently don't want/require/need global > > reachability for their hosts. Otherwise they would not NAT. > > So they probably don't want v6 either, so let them NAT with v4 only. You killed the context, but indeed if somebody doesn't want to have e2e connectivity then why should we force it upon them :) Greets, Jeroen -------------------------------------------------------------------- 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 Mar 31 11:26:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VJQePL011678; Mon, 31 Mar 2003 11:26:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VJQe6Z011677; Mon, 31 Mar 2003 11:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VJQbPL011670 for ; Mon, 31 Mar 2003 11:26:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VJQicU025781 for ; Mon, 31 Mar 2003 11:26:44 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21668 for ; Mon, 31 Mar 2003 12:26:34 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:26:34 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:26:33 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:26:33 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:26:33 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 31 Mar 2003 11:26:28 -0800 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Jeroen Massar'" Cc: Subject: RE: avoiding NAT with IPv6 Date: Mon, 31 Mar 2003 11:26:24 -0800 Message-Id: <076f01c2f7bb$6d2ce900$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.2.20030331123119.04a61410@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > There is a big difference between IPv6 site-local addresses > (whether "full", "moderate" or "exlusive") and the use of > private addressing behind IPv4 NATs. Without NAT, nodes that > only have an IPv6 site-local address will not be able to > communicate with the global Internet _at all_. Which some people consider to be a goal. > ... > The one-way reachability (outbound, but not inbound) that is > experienced by users of IPv4 NAT is a side-effect of NAT. No it is not. NAT is the act of mangling the header. One-way reachability is a filtering router. The fact that most common NAT products include filtering does not make filtering a side-effect of header mangling. > So, > if we are successful in avoiding NAT in IPv6, the "security" > models that depend on this one-way reachability won't apply in IPv6. Get real. Filtering WILL apply, because it is one component in a security model that IT managers will insist on. Their jobs are on the line, and they will use the tools they believe help. Filtering is not a complete security solution, but it is a layer that exists and it will continue. Please stop confusing the issue by associating NAT with security. > > >IMHO the real solution to this and some other problems we > >are currently seeing in IPv6 is really one thing which > >must be solved before anything else: IPv6 Multihoming > > I'm not sure how IPv6 Multihoming applies here. Could you explain? I am not sure what Jeroen's point is, but one approach to the multihoming problem is to provide sites with PI space. Since this space is stable, the uses of SL space that simply need stability would be covered. > > > > So, if we don't come up with a way to allow provider-independent > > > address allocation in IPv6, we will probably get IPv6<->IPv6 NAT. > > > >We don't want PI because that would also imply a routingtable > >explosion. PI thus is not the answer. > > The simplest ways to provide PI addresses imply routing table > explosion. There are people (in the IETF, IRTF and > elsewhere) working on mechanisms for provider-independent > addressing that avoid routing table explosion. I certainly > hope that they will be successful, as that would solve a lot > of problems. Don't hold your breath. > > >Taking a, imho, good application like [loadbalancers] in view NAT > >should not be forbidden... > > > >(Then again, the loadbalancer could just also have all the backends > >configured with the global IP and just forward the packets to the > >correct box... hmmm ;) > > I don't have any interest in eliminating load balancers, but > are you sure that this is how they work? What happens when > the server passes its IP addresses in FTP, SCTP or SIP > packets (or any other application-layer protocol)? Does the > loadbalancer also translate those addresses to point to the > loadbalancer, or is it assumed that the client node can (and > should) reach the server directly in those cases? While it may not be the most elegant, one way to deal with this type of loadbalancer would be to use MIPv6. Tony -------------------------------------------------------------------- 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 Mar 31 11:49:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VJnbPL011910; Mon, 31 Mar 2003 11:49:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VJnbEs011909; Mon, 31 Mar 2003 11:49:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VJnYPL011902 for ; Mon, 31 Mar 2003 11:49:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VJnfHP025192 for ; Mon, 31 Mar 2003 11:49:41 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11798 for ; Mon, 31 Mar 2003 12:49:34 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:49:23 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:46:12 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:49:12 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 19:49:12 Z Content-class: urn:content-classes:message Subject: RE: avoiding NAT with IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 2003 11:49:06 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F5045632@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcL3rsowetnP0oK+QsGBXKWBc/28/AADIypg From: "Michel Py" To: "Margaret Wasserman" , "Jeroen Massar" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VJnYPL011903 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > Margaret Wasserman wrote: > That depends on what you mean by "global reachability". > I am writing to you from behind a NAT right now. > From here, I can reach web sites on the global > Internet, etc. I can't run servers here Why is that? (note that I am not trying do defend or condone NAT by any means, just for my understanding). I run my HTTP, HTTPS, FTP, SMTP servers on RFC1918 addresses behind NAT. At home I also do p2p music sharing on RFC1918 behind NAT. This is an extremely common setup these days. > The one-way reachability (outbound, but not inbound) > that is experienced by users of IPv4 NAT is a side-effect > of NAT. So, if we are successful in avoiding NAT in IPv6, > the "security" models that depend on this one-way > reachability won't apply in IPv6. Correct, this is why we will need IPv6 firewalls. Although NAT itself does not perform stateful packet inspection for other purposes than ALGs, it does implement hard state that provides this "one-way reachability" which is a most desired feature of firewalls. > I don't have any interest in eliminating load balancers, > but are you sure that this is how they work? The ones that I have seen, yes. > What happens when the server passes its IP addresses in FTP, > SCTP or SIP packets (or any other application-layer protocol)? > Does the loadbalancer also translate those addresses to point > to the loadbalancer, You meant to the host I suppose and the answer is yes. There are ALGs in the load balancers that I have seen that rewrite packets and they do have the exact same issues as NAT WRT apps that embed IP addresses in the packet. The typical config of load balancers is that the load balancer's address is the one published in DNS, and the load balancer is indeed a NAT box that NATs traffic to the least busy server in a pool. Michel. -------------------------------------------------------------------- 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 Mar 31 12:38:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VKc5PL012864; Mon, 31 Mar 2003 12:38:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VKc5GU012863; Mon, 31 Mar 2003 12:38:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VKc1PL012856 for ; Mon, 31 Mar 2003 12:38:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VKc8HP012192 for ; Mon, 31 Mar 2003 12:38:09 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11853 for ; Mon, 31 Mar 2003 13:38:02 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:38:02 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:38:01 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:38:01 Z Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:38:01 Z Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CFB3A667B; Mon, 31 Mar 2003 15:36:11 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 31 Mar 2003 15:36:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] Date: Mon, 31 Mar 2003 15:36:10 -0500 Message-Id: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCF54@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 5.2 DNS [Re: Nodes Requirements Input] Thread-Index: AcL3nl94gQq0GoyES9CcnezQbNTuewAJqpzA From: "Bound, Jim" To: "Margaret Wasserman" Cc: "Brian E Carpenter" , X-OriginalArrivalTime: 31 Mar 2003 20:36:10.0421 (UTC) FILETIME=[29F31650:01C2F7C5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VKc1PL012857 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My point was operational use not theoretical. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, March 31, 2003 10:48 AM > To: Bound, Jim > Cc: Brian E Carpenter; ipng@sunroof.eng.sun.com > Subject: RE: 5.2 DNS [Re: Nodes Requirements Input] > > > > The IPv6 Node Requirements is intended to document the > minimal requirements for an IPv6 node, and a DNS resolver is > not one of those requirements. You can have a > perfectly-compliant IPv6 node that doesn't include any DNS support. > > If we start down the road of saying: > > "A node MUST include a DNS resolver if it needs to resolve DNS names." > > wouldn't this lead to: > > "A node MUST include SIP if it wants to use the Session > Initiation Protocol", etc.? > > Margaret > > > At 06:45 PM 3/18/2003 -0500, Bound, Jim wrote: > >Agreed. But how can a node find an address without MUST DNS. The > >point is that a requirement to use is based on the > situation. My point > >last night. > > > >/jim > > > > > > > > > > > -----Original Message----- > > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: Tuesday, March 18, 2003 4:45 PM > > > To: Bound, Jim > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: 5.2 DNS [Re: Nodes Requirements Input] > > > > > > > > > "Bound, Jim" wrote: > > > ... > > > > > > > > > > 5.2 DNS > > > > > > > > > > DNS, as described in [RFC-1034], [RFC-1035], > > > [RFC-1886], [RFC-3152] > > > > > and [RFC-3363] MAY be supported. Not all nodes > will need to > > > > > resolve > > > > > addresses. Note that RFC 1886 is currently being updated > > > > > [RFC-1886- > > > > > BIS]. > > > > > > > > DNS "use" is a MUST for correct node operation. MAY is absurd. > > > > > > Why would a thermostat need to resolve names? > > > > > > Brian > > > > > > >-------------------------------------------------------------------- > >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 Mar 31 12:48:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VKmoPL013109; Mon, 31 Mar 2003 12:48:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VKmoIw013108; Mon, 31 Mar 2003 12:48:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VKmkPL013101 for ; Mon, 31 Mar 2003 12:48:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VKmsHP015536 for ; Mon, 31 Mar 2003 12:48:54 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21126 for ; Mon, 31 Mar 2003 13:48:48 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:48:48 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:48:47 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:48:47 Z Received: from spoon.alink.net ([207.135.64.249] [207.135.64.249]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 20:48:47 Z Received: from iniche.com (host26.iniche.com [207.135.74.26]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id MAA24823 for ; Mon, 31 Mar 2003 12:48:46 -0800 (PST) Message-Id: <3E88A996.7882A273@iniche.com> Date: Mon, 31 Mar 2003 12:48:22 -0800 From: John Bartas Reply-To: jbartas@iniche.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Outlawing (Avoiding) NAT with IPv6 References: <963621801C6D3E4A9CF454A1972AE8F5045632@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, We may not have to worry about it - NAT is now illegal in 4 of the United States, and counting: http://news.com.com/2100-1028-994667.html One thing I have not seen addressed in this thread is anonymity. One reason I wrote my first NAT in 1996 was because I can do things on the net (like send this email), and no one could trace it back any further than my company DSL link. It's up to me if I want to identify myself or not. I don't see any good way to do this without NAT, which has well understood drawbacks. If IPv6 has a better anonymity solution, can someone point me to it? Or do I have to start working on NATv6? (See, this is why I don't always want to identify myself! :-) -JB- ############################################################# H (==)o(==) H John Bartas - Main Propeller head _I_ H InterNiche Technologies Inc. (408) 257-8014 x219 / \ H 1340 S. DeAnza Blvd. Suite 102 ----- H San Jose CA 95129 O O H jbartas@iniche.com " H www.iniche.com \___/ H -------------------------------------------------------------------- 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 Mar 31 13:09:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VL9JPL013460; Mon, 31 Mar 2003 13:09:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VL9Jgg013459; Mon, 31 Mar 2003 13:09:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VL9FPL013449 for ; Mon, 31 Mar 2003 13:09:15 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VL9MHP023084 for ; Mon, 31 Mar 2003 13:09:22 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20200 for ; Mon, 31 Mar 2003 13:09:17 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:09:16 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:06:08 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:09:16 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:09:15 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id A15418AD7; Mon, 31 Mar 2003 23:09:11 +0200 (CEST) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 7803E8A16; Mon, 31 Mar 2003 23:09:02 +0200 (CEST) From: "Jeroen Massar" To: , Subject: RE: Outlawing (Avoiding) NAT with IPv6 Date: Mon, 31 Mar 2003 23:10:05 +0200 Organization: Unfix Message-Id: <000901c2f7c9$e8287d50$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E88A996.7882A273@iniche.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VL9FPL013451 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John Bartas wrote: > We may not have to worry about it - NAT is now illegal > in 4 of the United States, and counting: > > http://news.com.com/2100-1028-994667.html I don't see anything in that article that applies to NAT's. It's about copyrights not about IP addressing maybe that's why I don't see it ;) > One thing I have not seen addressed in this thread is anonymity. One > reason I wrote my first NAT in 1996 was because I can do things on the > net (like send this email), and no one could trace it back any further > than my company DSL link. It's up to me if I want to identify myself or > not. > > I don't see any good way to do this without NAT, which has well > understood drawbacks. > > If IPv6 has a better anonymity solution, can someone point me to it? Or > do I have to start working on NATv6? (See, this is why I don't always > want to identify myself! :-) Email is SMTP which runs on top of TCP/IP. You could just let your SMTP service not log any headers and tada you are 'anonymous'. This is an application 'problem' not a stack 'problem'. Then again if you want to be 'anonymous' then don't use the internet there fortunatly are enough ways to find a person who is using it. Then again there are also enough ways of making finding a person quite hard. If you want to be anonymous you probably have something to hide which is not normal to do or not even talking about illegal things. And one of the few reasons to use 'anonymous' SMTP is to spam, eeuw... Greets, Jeroen -------------------------------------------------------------------- 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 Mar 31 13:34:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VLYSPL014082; Mon, 31 Mar 2003 13:34:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VLYSPo014081; Mon, 31 Mar 2003 13:34:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VLYPPL014074 for ; Mon, 31 Mar 2003 13:34:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VLYWcU014890 for ; Mon, 31 Mar 2003 13:34:32 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19259 for ; Mon, 31 Mar 2003 14:34:26 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:34:26 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:31:18 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:34:26 Z Received: from fridge.docomolabs-usa.com ([216.98.102.225] [216.98.102.225]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:34:24 Z Date: Mon, 31 Mar 2003 13:34:30 -0800 Subject: Re: Outlawing (Avoiding) NAT with IPv6 From: Alper Yegin To: , Message-Id: In-Reply-To: <3E88A996.7882A273@iniche.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We may not have to worry about it - NAT is now illegal in 4 of the > United States, and counting: > > http://news.com.com/2100-1028-994667.html > > One thing I have not seen addressed in this thread is anonymity. One > reason I wrote my first NAT in 1996 was because I can do things on the > net (like send this email), and no one could trace it back any further > than my company DSL link. It's up to me if I want to identify myself or > not. > > I don't see any good way to do this without NAT, which has well > understood drawbacks. > > If IPv6 has a better anonymity solution, can someone point me to it? Or > do I have to start working on NATv6? (See, this is why I don't always > want to identify myself! :-) Please see: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-07.txt You can search for "location privacy" in this draft. This protocol can help with what you are looking for without having to "break IP". alper > > -JB- > > ############################################################# > H > (==)o(==) H John Bartas - Main Propeller head > _I_ H InterNiche Technologies Inc. (408) 257-8014 x219 > / \ H 1340 S. DeAnza Blvd. Suite 102 > ----- H San Jose CA 95129 > O O H jbartas@iniche.com > " H www.iniche.com > \___/ H > -------------------------------------------------------------------- > 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 Mar 31 13:39:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VLdRPL014135; Mon, 31 Mar 2003 13:39:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VLdRPB014134; Mon, 31 Mar 2003 13:39:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VLdNPL014124 for ; Mon, 31 Mar 2003 13:39:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VLdUcU016605 for ; Mon, 31 Mar 2003 13:39:31 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01057 for ; Mon, 31 Mar 2003 14:39:25 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:38:41 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:38:40 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:38:40 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 21:38:40 Z Received: from cisco.com (dhcp-171-71-194-115.cisco.com [171.71.194.115]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA16586; Mon, 31 Mar 2003 13:38:32 -0800 (PST) Message-Id: <3E88B557.30900@cisco.com> Date: Mon, 31 Mar 2003 13:38:31 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Margaret Wasserman'" , "'Jeroen Massar'" , ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 References: <076f01c2f7bb$6d2ce900$ee1a4104@eagleswings> In-Reply-To: <076f01c2f7bb$6d2ce900$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > Margaret Wasserman wrote: > >>There is a big difference between IPv6 site-local addresses >>(whether "full", "moderate" or "exlusive") and the use of >>private addressing behind IPv4 NATs. Without NAT, nodes that >>only have an IPv6 site-local address will not be able to >>communicate with the global Internet _at all_. > > > Which some people consider to be a goal. When it's intended. However, site-local is "not the droids you're looking for". It's not a firewall. Don't position it as such. Eliot -------------------------------------------------------------------- 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 Mar 31 14:07:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VM7tPL014891; Mon, 31 Mar 2003 14:07:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VM7tuY014890; Mon, 31 Mar 2003 14:07:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VM7pPL014883 for ; Mon, 31 Mar 2003 14:07:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VM7xcU026770 for ; Mon, 31 Mar 2003 14:07:59 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14234 for ; Mon, 31 Mar 2003 15:07:51 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:07:47 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:04:39 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:07:47 Z Received: from spoon.alink.net ([207.135.64.249] [207.135.64.249]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:07:47 Z Received: from iniche.com (host26.iniche.com [207.135.74.26]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id OAA13699 for ; Mon, 31 Mar 2003 14:07:45 -0800 (PST) Message-Id: <3E88BC1A.66A2AD9D@iniche.com> Date: Mon, 31 Mar 2003 14:07:22 -0800 From: John Bartas Reply-To: jbartas@iniche.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Outlawing (Avoiding) NAT with IPv6 References: <000901c2f7c9$e8287d50$210d640a@unfix.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jeroen, Well, my main point was how to provide anonymity without forcing users to use NATv6. But.... Here's some other URLs which indicate that NAT is outlawed by some of this new legislation. What these laws proscribe, in general terms, is any technology which hides the actual source of an internet session. This pretty clearly covers NAT, Bluetooth, Proxy Servers, forwarding services, load balancers, and probably other things I haven't thought of yet. Long-term I don't think this group should reply on these laws as a solution to NATv6, for the same reasons that banning it in the RFC may not work. Here's the short explanation: http://www.theinquirer.net/?article=8595 Here's the URL of the Michigan law's official analysis: http://michiganlegislature.org/documents/2001-2002/billanalysis/house/htm/2001-HLA-6079-b.htm It says in part: "Telecommunications service and devices. Currently the code prohibits a person from manufacturing, possessing, "delivering", offering to deliver, or advertising a counterfeit telecommunications device or a telecommunications device, if he or she intends to use the device or to allow the device to be used--or knows or has reason to know that the device is intended to be used--for either of the following illicit purposes: · to obtain or attempt to obtain telecommunications service with the intent to avoid or aid or abet or cause another person to avoid any lawful charge for the service in violation of the prohibition described above; or · to conceal the existence or place of origin or destination of any telecommunications service ... When you read the surrounding definitions, this last clause clearly covers NAT, firewall proxies, I suspect this is unintentional; but for now NAT is illegal in Michigan. Jeroen Massar wrote: > > John Bartas wrote: > > > We may not have to worry about it - NAT is now illegal > > in 4 of the United States, and counting: > > > > http://news.com.com/2100-1028-994667.html > > I don't see anything in that article that applies to NAT's. > It's about copyrights not about IP addressing maybe that's > why I don't see it ;) > > > One thing I have not seen addressed in this thread is anonymity. > One > > reason I wrote my first NAT in 1996 was because I can do things on the > > net (like send this email), and no one could trace it back any further > > than my company DSL link. It's up to me if I want to identify myself > or > > not. > > > > I don't see any good way to do this without NAT, which has well > > understood drawbacks. > > > > If IPv6 has a better anonymity solution, can someone point me to > it? Or > > do I have to start working on NATv6? (See, this is why I don't always > > want to identify myself! :-) > > Email is SMTP which runs on top of TCP/IP. You could just let > your SMTP service not log any headers and tada you are 'anonymous'. > This is an application 'problem' not a stack 'problem'. > Then again if you want to be 'anonymous' then don't use the internet > there fortunatly are enough ways to find a person who is using it. > Then again there are also enough ways of making finding a person > quite hard. If you want to be anonymous you probably have something > to hide which is not normal to do or not even talking about illegal > things. > And one of the few reasons to use 'anonymous' SMTP is to spam, eeuw... > > Greets, > Jeroen -- -JB- ############################################################# H (==)o(==) H John Bartas - Main Propeller head _I_ H InterNiche Technologies Inc. (408) 257-8014 x219 / \ H 1340 S. DeAnza Blvd. Suite 102 ----- H San Jose CA 95129 O O H jbartas@iniche.com " H www.iniche.com \___/ H -------------------------------------------------------------------- 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 Mar 31 14:11:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMBYPL015109; Mon, 31 Mar 2003 14:11:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VMBYrY015107; Mon, 31 Mar 2003 14:11:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMBUPL015094 for ; Mon, 31 Mar 2003 14:11:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VMBbcU028062 for ; Mon, 31 Mar 2003 14:11:38 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13124 for ; Mon, 31 Mar 2003 15:11:32 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:11:31 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:11:27 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:11:27 Z Received: from spoon.alink.net ([207.135.64.249] [207.135.64.249]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:11:26 Z Received: from iniche.com (host26.iniche.com [207.135.74.26]) by spoon.alink.net (8.9.3/8.9.3) with ESMTP id OAA14682; Mon, 31 Mar 2003 14:11:23 -0800 (PST) Message-Id: <3E88BCF4.6748E4C0@iniche.com> Date: Mon, 31 Mar 2003 14:11:00 -0800 From: John Bartas Reply-To: jbartas@iniche.com X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US MIME-Version: 1.0 To: Alper Yegin CC: ipng@sunroof.eng.sun.com Subject: Re: Outlawing (Avoiding) NAT with IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alger, This looks like a potential solution. I would not have thought of looking into Mobile IPv6 for an anonymity service, but there it is. Of course it's illegal in Michigan (;-), but for the rest of the world it might be quite popular. Thanks, -JB- Alper Yegin wrote: > > > We may not have to worry about it - NAT is now illegal in 4 of the > > United States, and counting: > > > > http://news.com.com/2100-1028-994667.html > > > > One thing I have not seen addressed in this thread is anonymity. One > > reason I wrote my first NAT in 1996 was because I can do things on the > > net (like send this email), and no one could trace it back any further > > than my company DSL link. It's up to me if I want to identify myself or > > not. > > > > I don't see any good way to do this without NAT, which has well > > understood drawbacks. > > > > If IPv6 has a better anonymity solution, can someone point me to it? Or > > do I have to start working on NATv6? (See, this is why I don't always > > want to identify myself! :-) > > Please see: > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-07.txt > > You can search for "location privacy" in this draft. This protocol can help > with what you are looking for without having to "break IP". > > alper > > > > > -JB- > > > > ############################################################# > > H > > (==)o(==) H John Bartas - Main Propeller head > > _I_ H InterNiche Technologies Inc. (408) 257-8014 x219 > > / \ H 1340 S. DeAnza Blvd. Suite 102 > > ----- H San Jose CA 95129 > > O O H jbartas@iniche.com > > " H www.iniche.com > > \___/ H > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- -- -JB- ############################################################# H (==)o(==) H John Bartas - Main Propeller head _I_ H InterNiche Technologies Inc. (408) 257-8014 x219 / \ H 1340 S. DeAnza Blvd. Suite 102 ----- H San Jose CA 95129 O O H jbartas@iniche.com " H www.iniche.com \___/ H -------------------------------------------------------------------- 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 Mar 31 14:44:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMicPL015866; Mon, 31 Mar 2003 14:44:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VMicmL015865; Mon, 31 Mar 2003 14:44:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMiZPL015858 for ; Mon, 31 Mar 2003 14:44:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VMigHP025952 for ; Mon, 31 Mar 2003 14:44:42 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06202 for ; Mon, 31 Mar 2003 15:44:36 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:44:36 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:44:36 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:44:36 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:44:35 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 31 Mar 2003 14:44:34 -0800 Reply-To: From: "Tony Hain" To: , Subject: RE: Outlawing (Avoiding) NAT with IPv6 Date: Mon, 31 Mar 2003 14:44:26 -0800 Message-Id: <07a201c2f7d7$157391c0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E88A996.7882A273@iniche.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John Bartas wrote: > If IPv6 has a better anonymity solution, can someone > point me to it? Or do I have to start working on NATv6? > (See, this is why I don't always want to identify myself! > :-) See RFC 3041 - It does exactly what you want without the drawbacks of NAT. Tony -------------------------------------------------------------------- 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 Mar 31 14:53:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMrHPL015976; Mon, 31 Mar 2003 14:53:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VMrGUB015974; Mon, 31 Mar 2003 14:53:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMrDPL015967 for ; Mon, 31 Mar 2003 14:53:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VMrJcU012768 for ; Mon, 31 Mar 2003 14:53:20 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10758 for ; Mon, 31 Mar 2003 15:53:14 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:53:14 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:53:13 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:53:13 Z Received: from leapster.dwerryhouse.com.au ([203.30.75.104] [203.30.75.104]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:53:11 Z Received: by leapster.dwerryhouse.com.au (Postfix, from userid 501) id 78765146CF; Tue, 1 Apr 2003 08:53:09 +1000 (EST) Date: Tue, 1 Apr 2003 08:53:09 +1000 From: "Nick 'Sharkey' Moore" To: "Charles E. Perkins" Cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: DAD in node requirements draft Message-Id: <20030331225309.GA13421@zoic.org> Mail-Followup-To: "Charles E. Perkins" , Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com References: <20030326114233.12CAA791@starfruit.itojun.org> <3E81E5F5.572CAFFA@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E81E5F5.572CAFFA@iprg.nokia.com> User-Agent: Mutt/1.3.28i X-URL: http://zoic.org/sharkey/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Dang! I'd missed this thread under a pile of site-local discussion] On Wed, Mar 26, 2003 at 09:40:05AM -0800, Charles E. Perkins wrote: > > Jun-ichiro itojun Hagino wrote: > > > how can you prevent random other node to assign P::X (which you are > > using and verified fe80::X by DAD) on the interface? DIID does not > > work in practice. > > That's not supposed to happen, because the other node would > be prevented from autoconfiguring the corresponding link-local > address. So long as all nodes DAD for fe80::X before using Y::X, indeed. And it seems to me that it's unsafe to do this any other way, since there's plenty of stuff around doing "DIID". On the other hand, the 3041 and CGA people are probably wondering why they have to check this silly fe80::X first! I myself am happy to go with whichever solution causes least harm ... > Perhaps you are suggesting that bad things can happen if > nodes do not do DAD, or exhibit some other protocol violation. Such as Optimistic DAD? I started on draft-moore-ipv6-optimistic-dad shortly after Yokohama, where I got the impression that DIID was on the way out. It's easily retrofitted to the DIID way of thinking, Ed Remmell did this in his implementation. I'm interested in hearing the thoughts of the group ... cheers, Nick -- Nick 'Sharkey' Moore -------------------------------------------------------------------- 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 Mar 31 14:53:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMrhPL016004; Mon, 31 Mar 2003 14:53:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h2VMrhFA016003; Mon, 31 Mar 2003 14:53:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h2VMrbPL015989 for ; Mon, 31 Mar 2003 14:53:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h2VMrjHP028764 for ; Mon, 31 Mar 2003 14:53:45 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10996 for ; Mon, 31 Mar 2003 15:53:39 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:52:22 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:47:51 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:47:51 Z Received: from tndh.net (tndh.net [4.65.19.240]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Mon, 31 Mar 2003 22:47:51 Z Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 31 Mar 2003 14:47:50 -0800 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" Cc: "'Margaret Wasserman'" , "'Jeroen Massar'" , Subject: RE: avoiding NAT with IPv6 Date: Mon, 31 Mar 2003 14:47:42 -0800 Message-Id: <07a301c2f7d7$8a0751c0$ee1a4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3E88B557.30900@cisco.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h2VMrcPL015990 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eliot Lear wrote: > When it's intended. However, site-local is "not the droids you're > looking for". It's not a firewall. Don't position it as such. I did not call it a firewall, so don't put words in my mouth. It is a well-known routing filter, nothing more. Routing filters are used as one component of security, and having a well-known one means it is more likely someone else will also be filtering it to cover any configuration mistakes. Tony -------------------------------------------------------------------- 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 Mar 31 16:04:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3104BPL016797; Mon, 31 Mar 2003 16:04:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3104B8g016796; Mon, 31 Mar 2003 16:04:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h31047PL016789 for ; Mon, 31 Mar 2003 16:04:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h3104EcU008938 for ; Mon, 31 Mar 2003 16:04:15 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27213 for ; Mon, 31 Mar 2003 17:04:09 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:04:09 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:04:09 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:04:08 Z Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:04:08 Z Received: from cisco.com (dhcp-171-71-194-115.cisco.com [171.71.194.115]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA03556; Mon, 31 Mar 2003 16:04:06 -0800 (PST) Message-Id: <3E88D775.7000903@cisco.com> Date: Mon, 31 Mar 2003 16:04:05 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: avoiding NAT with IPv6 References: <07a301c2f7d7$8a0751c0$ee1a4104@eagleswings> In-Reply-To: <07a301c2f7d7$8a0751c0$ee1a4104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > Eliot Lear wrote: > >>When it's intended. However, site-local is "not the droids you're >>looking for". It's not a firewall. Don't position it as such. > > > I did not call it a firewall, so don't put words in my mouth. My apologies. The address by itself is no filter at all, and requires specific implementation functionality that is really no different than any other address. Eliot -------------------------------------------------------------------- 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 Mar 31 16:40:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h310eLPL017140; Mon, 31 Mar 2003 16:40:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h310eLCh017139; Mon, 31 Mar 2003 16:40:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h310eIPL017132 for ; Mon, 31 Mar 2003 16:40:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h310ePHP004702 for ; Mon, 31 Mar 2003 16:40:25 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08174 for ; Mon, 31 Mar 2003 16:40:20 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:40:19 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:37:11 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:40:19 Z Received: from purgatory.unfix.org (purgatory.unfix.org [195.64.92.136]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 00:40:18 Z Received: from localhost (localhost [127.0.0.1]) by purgatory.unfix.org (Postfix) with ESMTP id 9DB318AF8; Tue, 1 Apr 2003 02:40:15 +0200 (CEST) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id D7D828AA9; Tue, 1 Apr 2003 02:40:04 +0200 (CEST) From: "Jeroen Massar" To: "'Margaret Wasserman'" Cc: Subject: RE: avoiding NAT with IPv6 Date: Tue, 1 Apr 2003 02:41:10 +0200 Organization: Unfix Message-Id: <001701c2f7e7$65517b20$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: <5.1.0.14.2.20030331123119.04a61410@mail.windriver.com> X-Virus-Scanned: by AMaViS @ purgatory.unfix.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman [mailto:mrw@windriver.com] wrote: > Hi Jeroen, > > >These enterprises apparently don't want/require/need global > >reachability for their hosts. Otherwise they would not NAT. > > That depends on what you mean by "global reachability". > I am writing to you from behind a NAT right now. From here, > I can reach web sites on the global Internet, etc. I can't > run servers here, so I need to depend on my friends to do > that for me. I rather meant end-to-end connectivity which makes the sentence have a completely different meaning. Note that my boxes are also living behind a NAT in IPv4 but they do have global connectivity in IPv6. I rather have e2e because then every machine can also do all the really interresting applications like H323. > >IMHO the real solution to this and some other problems we > >are currently seeing in IPv6 is really one thing which > >must be solved before anything else: IPv6 Multihoming > > I'm not sure how IPv6 Multihoming applies here. Could you > explain? Michel Py explained this 'solution' quite well. He's then also quite busy on the IPv6 multihoming front :) > > > So, if we don't come up with a way to allow > > > provider-independent address > > > allocation in IPv6, we will probably get IPv6<->IPv6 NAT. > > > >We don't want PI because that would also imply a routingtable > >explosion. PI thus is not the answer. > > The simplest ways to provide PI addresses imply routing table > explosion. There are people (in the IETF, IRTF and elsewhere) > working on mechanisms for provider-independent addressing that > avoid routing table explosion. I certainly hope that they will > be successful, as that would solve a lot of problems. I hope for them to be sucessful too but I have little faith in it. > >Taking a, imho, good application like [loadbalancers] in view > >NAT should not be forbidden... > > > >(Then again, the loadbalancer could just also have all the > >backends configured with the global IP and just forward the > >packets to the correct box... hmmm ;) > > I don't have any interest in eliminating load balancers, but > are you sure that this is how they work? What happens when > the server passes its IP addresses in FTP, SCTP or SIP > packets (or any other application-layer protocol)? Does > the loadbalancer also translate those addresses to point to > the loadbalancer, or is it assumed that the client node > can (and should) reach the server directly in those cases? What I have seen they do. Though if I would have to implement one I'd quite probably go for the second version which doesn't need any NATting but just some maintainance in the loadbalancer describing which host is connected to which backend thus making the loadbalancer a policy based router. Should be quite easy to built too I think. But I also think that the real builders can comment on these situations. Nevertheless it would be great if loadbalancers sported IPv6 as it would mean that they also could handle huge sites like CNN and Google which would be one way to allow them to upgrade to IPv6. Greets, Jeroen -------------------------------------------------------------------- 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 Mar 31 17:11:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h311B7PL017486; Mon, 31 Mar 2003 17:11:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h311B7DJ017485; Mon, 31 Mar 2003 17:11:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h311B4PL017478 for ; Mon, 31 Mar 2003 17:11:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h311BBHP013603 for ; Mon, 31 Mar 2003 17:11:11 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02937 for ; Mon, 31 Mar 2003 18:11:05 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:10:37 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:07:00 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:09:57 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:09:57 Z Content-class: urn:content-classes:message Subject: RE: avoiding NAT with IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 2003 17:09:57 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F709@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: avoiding NAT with IPv6 Thread-Index: AcL36DEJM+04lkEcSnKVKfetf7NVbQAAcS0g From: "Michel Py" To: "Jeroen Massar" , "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h311B4PL017479 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jeroen Massar wrote: > Nevertheless it would be great if loadbalancers sported IPv6 > as it would mean that they also could handle huge sites like > CNN and Google which would be one way to allow them to upgrade > to IPv6. Yep. As I have said before, as long as CNN, Google, eBay, eTrade, Yahoo and consorts are not IPv6 enabled (which also means multihomed for these guys) IPv6 does not exist for the general public. The need for load balancers today is not too much performance (a dual P4Xeon with tons of two-way interleaved memory and 533 FSB can deliver something between OC-3 and OC-12 speeds) but with un-interrupted service. For these guys, there is no such thing as taking the server off-line maintenance. The nice thing with load balancers is that they allow to "busy-out" a server in the pool, when all active connections are gone it can be rebooted and/or upgraded. Michel. -------------------------------------------------------------------- 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 Mar 31 17:33:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h311X9PL017912; Mon, 31 Mar 2003 17:33:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h311X9NX017911; Mon, 31 Mar 2003 17:33:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h311X6PL017904 for ; Mon, 31 Mar 2003 17:33:06 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h311XDcU008113 for ; Mon, 31 Mar 2003 17:33:13 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00578 for ; Mon, 31 Mar 2003 17:33:07 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:33:07 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:33:07 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:33:07 Z Received: from pguin2.txc.com (pguin2.txc.com [208.5.237.254]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 01:33:07 Z Received: from txc.com ([172.17.0.226]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id h311X0p04386; Mon, 31 Mar 2003 20:33:01 -0500 Message-Id: <3E89169C.C3433B49@txc.com> Date: Mon, 31 Mar 2003 20:33:32 -0800 From: Alex Conta X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft IPv6 Minutes from Atlanta IETF References: <068d01c2f58c$341b8300$ee1a4104@eagleswings> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDEA5075FDA379FCC99290D19" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msDEA5075FDA379FCC99290D19 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony, Tony Hain wrote: > [...] > the decision was > based on fear of NAT [...] > Local > address space is a filtering function, and exists with or without header > mangling. Filtering will exist in real network deployments, so having a > space set aside for that purpose does not change the architectural > reality. > This is a good point. Regards, Alex --------------msDEA5075FDA379FCC99290D19 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKQwYJKoZIhvcNAQcCoIIKNDCCCjACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B88wggSZMIIEAqADAgECAhAwgIjt1LtpV2AM64D0R8bCMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAyMDkyMDAwMDAw MFoXDTAzMTAwNDIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFIjccjs9g z0DiQcpTsg+mbY5L+R2YaTNN6k2fRGSLMLitaA2YwdeN3goXG45bXCP8DldBS38EWHFT2/5Q cy9HnNQaS1GnG2xzngdev5HpVm/oAy1M9YPt96Zp2W5MKGIb87vxyXvb1KqRMA9paf/6xZ2C B4tH127oHyF1xT4k8wIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGe BgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3Mg Q1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ YIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdl ODQyNjYxMjUwMjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20v Y2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQBUOS83AALNc8pTZDApKndtQBiFQLPTu5ZL pE1TDsyd4y75K3gXUvqlprCFY8HgKwodqs9wTltqYRlvhZVlMXu1y0g8Z3MJ9KSddePYuuli jop+PplaAHS7DHXDJNNQt+n2i2K4j4uJFokE2JnvaEyBEHjtTmIt+JjS2Dygm57mwzCCAy4w ggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1 MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xU v7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbaw NkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQAB o3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsG CCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYB Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEe kmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPH vhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWi kK5uMYICPDCCAjgCAQEwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBW YWxpZGF0ZWQCEDCAiO3Uu2lXYAzrgPRHxsIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA0MDEwNDMzMzRaMCMGCSqGSIb3DQEJ BDEWBBS8TMF9Va/ngBgPQ7ZJmSoQeDVY+jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIB KDANBgkqhkiG9w0BAQEFAASBgLh23WBDKR7qbQ7f1lr7Ujqso+CDwFqJEj43RZpnCUssKKUl I2TEoClKZwgiXgG52pEhRmh8zEZconrb0AGby3krMl41e9JU4cH3zkcdapGSO951M9YBWylF Dr6LW8+iSiGAq0JtHkq5pmaLUmjNpvt8f4m6uiBVS5n/0BEOftw0 --------------msDEA5075FDA379FCC99290D19-- -------------------------------------------------------------------- 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 Mar 31 18:51:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h312pvPL018458; Mon, 31 Mar 2003 18:51:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h312pvYt018457; Mon, 31 Mar 2003 18:51:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h312prPL018450 for ; Mon, 31 Mar 2003 18:51:53 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h312q0HP013238 for ; Mon, 31 Mar 2003 18:52:00 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13483 for ; Mon, 31 Mar 2003 18:51:55 -0800 (PST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 02:51:54 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 02:51:45 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 02:51:45 Z Received: from ALPHA8.ITS.MONASH.EDU.AU (ALPHA8.ITS.MONASH.EDU.AU [130.194.1.8]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 02:51:44 Z Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KU7P4POWSC9AU674@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 12:42:14 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 4AECB2000C; Tue, 01 Apr 2003 12:42:14 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 2EB8420008; Tue, 01 Apr 2003 12:42:14 +1000 (EST) Date: Tue, 01 Apr 2003 12:42:13 +1000 From: Greg Daley Subject: Re: Outlawing (Avoiding) NAT with IPv6 To: jbartas@iniche.com Cc: Alper Yegin , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-Id: <3E88FC85.3040203@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3E88BCF4.6748E4C0@iniche.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John and Alper, John Bartas wrote: > Hi Alger, > > This looks like a potential solution. I would not have thought of > looking into Mobile IPv6 for an anonymity service, but there it is. > > Of course it's illegal in Michigan (;-), but for the rest of the world > it might be quite popular. > > Thanks, I think that Hesham et al. were already aware of the issue in Michigan. They have provided an 'M' flag for the local binding update. Greg Daley -------------------------------------------------------------------- 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 Mar 31 19:09:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h31398PL018851; Mon, 31 Mar 2003 19:09:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h31397iH018850; Mon, 31 Mar 2003 19:09:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h31394PL018843 for ; Mon, 31 Mar 2003 19:09:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h3139BHP017199 for ; Mon, 31 Mar 2003 19:09:11 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22310 for ; Mon, 31 Mar 2003 19:09:05 -0800 (PST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 03:09:05 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 03:05:57 Z Received: from mms11bas.mms.us.syntegra.com (mms11bas.mms.us.syntegra.com [150.143.167.10]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 03:09:05 Z Received: from SERVER2000.arneill-py.sacramento.ca.us (arneill-py.sacramento.ca.us [209.233.126.65]) by relay11.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 03:09:05 Z Content-class: urn:content-classes:message Subject: RE: A use for site local addresses? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Mar 2003 19:09:04 -0800 Message-Id: <963621801C6D3E4A9CF454A1972AE8F504F70C@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A use for site local addresses? Thread-Index: AcL3mf4dKg4H9PJKSuSbEmMZ7YSC3AAYY1pw From: "Michel Py" To: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h31394PL018844 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian E Carpenter wrote: > IMHO it doesn't make a case for SLs in their present > incarnation (i.e. ambiguous address space). Note that if the present state is still ambiguous, it's largely due to the fact that authors of drafts to make them unique (non-ambiguous) namely Bob Hinden, Charlie Perkins and myself have kind of put their drafts on the back burner waiting for this site-local turmoil to settle down. Michel. -------------------------------------------------------------------- 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 Mar 31 20:47:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h314lKPL019193; Mon, 31 Mar 2003 20:47:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h314lKv8019192; Mon, 31 Mar 2003 20:47:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h314lGPL019185 for ; Mon, 31 Mar 2003 20:47:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h314lNcU025549 for ; Mon, 31 Mar 2003 20:47:23 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA19876 for ; Mon, 31 Mar 2003 21:47:18 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 04:47:17 Z Received: from mms01bms.mms.us.syntegra.com (mms01bms.mms.us.syntegra.com [150.143.103.150]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 04:47:16 Z Received: from mms02bas.mms.us.syntegra.com (mms02bas.mms.us.syntegra.com [150.143.103.20]) by mms01bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 04:47:16 Z Received: from devil.pp.htv.fi ([213.243.180.132] [213.243.180.132]) by relay2.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 04:47:15 Z Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h314mE4l031580; Tue, 1 Apr 2003 07:48:15 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h314mBSN031579; Tue, 1 Apr 2003 07:48:11 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: DAD in node requirements draft From: Mika Liljeberg To: "Nick 'Sharkey' Moore" Cc: "Charles E. Perkins" , Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com In-Reply-To: <20030331225309.GA13421@zoic.org> References: <20030326114233.12CAA791@starfruit.itojun.org> <3E81E5F5.572CAFFA@iprg.nokia.com> <20030331225309.GA13421@zoic.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1049172479.29198.58.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2003 07:48:09 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Nick, On Tue, 2003-04-01 at 01:53, Nick 'Sharkey' Moore wrote: > [Dang! I'd missed this thread under a pile of site-local discussion] ;-) > So long as all nodes DAD for fe80::X before using Y::X, indeed. > And it seems to me that it's unsafe to do this any other way, > since there's plenty of stuff around doing "DIID". On the > other hand, the 3041 and CGA people are probably wondering why > they have to check this silly fe80::X first! Well, they have to do either DAD or DIID anyway. I don't see why they should care which. > I myself am happy to go with whichever solution causes least > harm ... The safe way, in my opinion, is for all nodes to defend their IDs against both DAD and DIID, regardless of which approach they use themselves. I.e., always respond to both fe80::X and P::X. This way DAD and DIID can happily coexist on a network. Nodes that want the benefits of a unique ID can do DIID. Nodes that want to share an ID can do DAD. The DAD vs DIID behaviour could even be configurable per interface. > > Perhaps you are suggesting that bad things can happen if > > nodes do not do DAD, or exhibit some other protocol violation. > > Such as Optimistic DAD? I started on draft-moore-ipv6-optimistic-dad > shortly after Yokohama, where I got the impression that DIID > was on the way out. I sure hope not. I don't think we will be changing our implementation, unless DIID becomes expressly forbidden by a future standards track RFC. I would be .. somewhat opposed to that. > It's easily retrofitted to the DIID way of > thinking, Ed Remmell did this in his implementation. > > I'm interested in hearing the thoughts of the group ... For reasons of efficiency, DIID would seem to make more sense for mobile nodes. MikaL -------------------------------------------------------------------- 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 Mar 31 22:02:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3162NPL019953; Mon, 31 Mar 2003 22:02:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h3162NUv019952; Mon, 31 Mar 2003 22:02:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h3162KPL019945 for ; Mon, 31 Mar 2003 22:02:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h3162RcU011403 for ; Mon, 31 Mar 2003 22:02:27 -0800 (PST) Received: from relay11.sun.com (ip150143-167-14.us.syntegra.com [150.143.167.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24940 for ; Mon, 31 Mar 2003 23:02:23 -0700 (MST) Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay11i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:02:23 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:02:19 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:02:18 Z Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:02:18 Z Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5BAE16A901; Tue, 1 Apr 2003 09:02:17 +0300 (EEST) Message-Id: <3E892B37.5020104@kolumbus.fi> Date: Tue, 01 Apr 2003 09:01:27 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Node requirements re RFC 2893 References: <3E8853A9.66D4DD04@hursley.ibm.com> In-Reply-To: <3E8853A9.66D4DD04@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > draft-ietf-ipv6-node-requirements-03.txt includes: > > >>6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 >> >> If an IPv6 node implement dual stack and/or tunneling, then RFC2893 >> MUST be supported. > > > This is a little unclear due to the "and/or". Could we have > > If an IPv6 node implements dual stack operation, or IPv6-in-IPv4 > tunneling, or both, then the relevant sections of RFC2893 > MUST be supported. Ok. Jari -------------------------------------------------------------------- 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 Mar 31 22:26:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h316QlPL020273; Mon, 31 Mar 2003 22:26:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h316Ql3A020272; Mon, 31 Mar 2003 22:26:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h316QhPL020265 for ; Mon, 31 Mar 2003 22:26:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h316QocU016847 for ; Mon, 31 Mar 2003 22:26:51 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11399 for ; Mon, 31 Mar 2003 23:26:45 -0700 (MST) From: john.loughney@nokia.com Received: from mms11es.mms.us.syntegra.com (mms11es.mms.us.syntegra.com [150.143.168.10]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:26:45 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms11es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:26:44 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:26:44 Z Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 06:26:44 Z Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h316Uc505067 for ; Tue, 1 Apr 2003 09:30:38 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 09:26:38 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 09:26:38 +0300 Received: from esebe006.NOE.Nokia.com ([172.21.138.46]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 09:26:37 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 09:26:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Node requirements re RFC 2893 Date: Tue, 1 Apr 2003 09:26:35 +0300 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Node requirements re RFC 2893 Thread-Index: AcL3lzz6ajUK0Xg5TVyzi1ELqOrczgAgFvNA To: , X-OriginalArrivalTime: 01 Apr 2003 06:26:37.0378 (UTC) FILETIME=[A60FBA20:01C2F817] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h316QiPL020266 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > draft-ietf-ipv6-node-requirements-03.txt includes: > > > 6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 > > > > If an IPv6 node implement dual stack and/or tunneling, > then RFC2893 > > MUST be supported. > > This is a little unclear due to the "and/or". Could we have > > If an IPv6 node implements dual stack operation, or IPv6-in-IPv4 > tunneling, or both, then the relevant sections of RFC2893 > MUST be supported. > Thanks - that looks better to me. I will add it. br, John -------------------------------------------------------------------- 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 Mar 31 23:36:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h317akPL021218; Mon, 31 Mar 2003 23:36:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h317akfD021217; Mon, 31 Mar 2003 23:36:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h317ahPL021210 for ; Mon, 31 Mar 2003 23:36:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h317apcU003077 for ; Mon, 31 Mar 2003 23:36:51 -0800 (PST) Received: from relay2.sun.com (ip150143-103-24.mms.us.syntegra.com [150.143.103.24] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11049 for ; Tue, 1 Apr 2003 00:36:45 -0700 (MST) Received: from mms02es.mms.us.syntegra.com (mms02es.mms.us.syntegra.com [150.143.103.140]) by relay2i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:36:45 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms02es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:36:45 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:36:44 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:36:42 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h317YTD11963; Tue, 1 Apr 2003 10:34:30 +0300 Date: Tue, 1 Apr 2003 10:34:29 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: jbartas@iniche.com, Subject: RE: Outlawing (Avoiding) NAT with IPv6 In-Reply-To: <07a201c2f7d7$157391c0$ee1a4104@eagleswings> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 31 Mar 2003, Tony Hain wrote: > John Bartas wrote: > > If IPv6 has a better anonymity solution, can someone > > point me to it? Or do I have to start working on NATv6? > > (See, this is why I don't always want to identify myself! > > :-) > > See RFC 3041 - It does exactly what you want without the drawbacks of > NAT. NAT, applied *where*? On your DSL/cablemodem/etc. box -- about right. By the ISP? RFC3041 doesn't give you anything except a false sense of anonomity and broken apps. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 31 23:39:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h317dOPL021244; Mon, 31 Mar 2003 23:39:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h317dOwi021243; Mon, 31 Mar 2003 23:39:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h317dKPL021233 for ; Mon, 31 Mar 2003 23:39:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h317dSHP012298 for ; Mon, 31 Mar 2003 23:39:28 -0800 (PST) Received: from relay12.sun.com (ip150143-167-24.us.syntegra.com [150.143.167.24]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12581 for ; Tue, 1 Apr 2003 00:39:20 -0700 (MST) Received: from mms12es.mms.us.syntegra.com (mms12es.mms.us.syntegra.com [150.143.168.20]) by relay12i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:38:22 Z Received: from mms11bms.mms.us.syntegra.com (mms11bms.mms.us.syntegra.com [150.143.168.30]) by mms12es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:35:04 Z Received: from mms12bas.mms.us.syntegra.com (mms12bas.mms.us.syntegra.com [150.143.167.20]) by mms11bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:38:13 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay12.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:38:12 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h317bsJ11986; Tue, 1 Apr 2003 10:37:54 +0300 Date: Tue, 1 Apr 2003 10:37:54 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Jeroen Massar , Margaret Wasserman , Subject: RE: avoiding NAT with IPv6 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F709@server2000.arneill-py.sacramento.ca.us> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 31 Mar 2003, Michel Py wrote: > > Jeroen Massar wrote: > > Nevertheless it would be great if loadbalancers sported IPv6 > > as it would mean that they also could handle huge sites like > > CNN and Google which would be one way to allow them to upgrade > > to IPv6. > > Yep. As I have said before, as long as CNN, Google, eBay, eTrade, Yahoo > and consorts are not IPv6 enabled (which also means multihomed for these > guys) IPv6 does not exist for the general public. Not quite: I disagree with your last statement. Nothing stipulates that all, or even a commonly used part of, Internet applications must use IPv6 before "IPv6 exists for the general public". For example, a single popular p2p app could do it just fine. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 Mar 31 23:49:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h317nsPL021646; Mon, 31 Mar 2003 23:49:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h317nsE3021645; Mon, 31 Mar 2003 23:49:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h317npPL021638 for ; Mon, 31 Mar 2003 23:49:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h317nxcU006050 for ; Mon, 31 Mar 2003 23:49:59 -0800 (PST) Received: from relay1.sun.com (ip150143-103-14.mms.us.syntegra.com [150.143.103.14] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01794 for ; Tue, 1 Apr 2003 00:49:50 -0700 (MST) Received: from mms01es.mms.us.syntegra.com (mms01es.mms.us.syntegra.com [150.143.103.130]) by relay1i.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:49:01 Z Received: from mms02bms.mms.us.syntegra.com (mms02bms.mms.us.syntegra.com [150.143.103.160]) by mms01es.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:49:01 Z Received: from mms01bas.mms.us.syntegra.com (mms01bas.mms.us.syntegra.com [150.143.103.10]) by mms02bms.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:49:01 Z Received: from netcore.fi (netcore.fi [193.94.160.1]) by relay1.sun.com with ESMTP for ipng@sunroof.eng.sun.com; Tue, 1 Apr 2003 07:49:00 Z Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h317m4S12070; Tue, 1 Apr 2003 10:48:04 +0300 Date: Tue, 1 Apr 2003 10:48:04 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: "'Tim Chown'" , Subject: RE: A use for site local addresses? In-Reply-To: <076801c2f7aa$d5126a10$ee1a4104@eagleswings> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 31 Mar 2003, Tony Hain wrote: > Pekka Savola wrote: > > Route advertisements with long-enough lifetimes and > > fast-enough _deprecation_ (when reconnecting) seems one > > approach to look at more > > closely, IMO. > > Rather than continue to send this nonsense, please look closely at it > because you will find that it is a seriously broken model. Wow -- wait a second, you threw the first rock.. :-) > Deprecation > at reconnection will cause internal connections to drop. Wrong. "deprecated" in RFC2461 terms basically means "address is still assigned, but don't establish new connections with the address" Deprecated addresses can be used juuuust fine for existing connections. deprecated != invalidated > If you delay > the deprecation, connections to the site with the valid allocation will > not be possible. True, to an extent. The big thing is the window between getting new addresses and deprecating old ones; that is, ensuring that packets are not sourced with the old, broken addresses to the _Internet_. Which is why such windows must be minimized or eliminated, as above. However, you could implement a source address check in the border router -- like as proposed in host-centric multihoming -- so the nodes could pick the right address, even in circumstances like this. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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 --------------------------------------------------------------------